Core Lightning v25.12.1: Critical patch for stuck on-chain funds | Bitcoin Index

If you’re running Core Lightning v25.12 or created a new node since early December 2025, you need to upgrade to v25.12.1 now. Especially if you’ve noticed your on-chain funds won’t move.

On January 16, 2026, Blockstream released Core Lightning v25.12.1, a critical point release fixing a signature verification bug that could leave your bitcoin stuck. The bug affected new nodes created with v25.12 (released December 4, 2025). These nodes could receive on-chain funds but couldn’t spend them. The signing code and the address generation code were speaking different languages.

The release also patches two separate payment plugin crashes that caused entire nodes to shut down unexpectedly.

What broke: signature mismatch left funds stuck

The most severe issue hit new nodes created by Core Lightning v25.12 or later. These nodes couldn’t sign on-chain transactions for non-taproot addresses. When you tried to open a channel or withdraw funds, you’d see this error:

Error broadcasting transaction: error code: -26
mempool-script-verify-flag-failed (Script failed an OP_EQUALVERIFY operation)

Your bitcoin was visible in listfunds but completely immovable. One user reported: “I can see the funds in the addresses that lightning-cli listfunds lists.” But attempting any on-chain transaction failed with the same script verification error.

Why it happened: Version 25.12 switched new nodes to BIP-39 12-word mnemonic phrases with BIP-86 key derivation (the standard for Taproot wallets). The wallet code correctly generated addresses using BIP-86. The signing code still used the old BIP-32 derivation. Addresses and signatures didn’t match. Transaction validation failed.

As Rusty Russell noted in the fix, “the signing code was not changed to match the address generation code in the wallet.” Classic incomplete migration bug.

Payment crashes shut down nodes

Two separate crashes in payment plugins caused entire Lightning nodes to shut down:

Pay plugin crash: Assertion failure when handling errors from multi-hop routehints. Because the pay plugin is marked “important,” its crash triggered a full lightningd shutdown. Fixed in PR #8829.
Askrene plugin crash: Corner case in payment flow calculations when channel fees exceeded 32-bit integers. Fixed in PR #8832.

Node operators experienced unexpected shutdowns when attempting certain payment scenarios, particularly those involving routehints or high-fee channels. User michael1011 reported the crash on January 11, 2026.

How BIP-86 vs BIP-32 caused the mess

Core Lightning v25.12 introduced a major change to how new node secrets are stored. Old nodes (pre-v25.12) used a 32-byte binary hsm_secret file with BIP-32 key derivation. You had to back up the exact file. New nodes (v25.12+) use BIP-39 12-word mnemonic phrases with BIP-86 key derivation. You can write down 12 words and recreate your wallet.

BIP-32 is the traditional Hierarchical Deterministic wallet standard. It’s been around since Bitcoin’s early days.

BIP-86 is the newer standard for Taproot wallets. It uses a different derivation path (m/86'/0'/0'/0/0 instead of m/44'/0'/0'/0/0) and applies a Taproot tweak to the internal key:

output_key = internal_key + int(HashTapTweak(bytes(internal_key)))G

BIP-86 offers better privacy and forward compatibility with modern Bitcoin wallets. Switching to it makes sense. The problem: v25.12 changed address generation to BIP-86 but forgot to update the signing code. Addresses generated one way, signatures computed another way. Mismatch. Transaction rejected by mempool.

Version 25.12.1 completes the migration by updating the signing code to use BIP-86 derivation for mnemonic-based wallets.

Who should upgrade immediately

Critical if:

You created a new Core Lightning node on v25.12 (December 4, 2025 to January 16, 2026)
You’re running v25.12 and seeing on-chain transaction failures
You’re experiencing unexpected node shutdowns during payments

Recommended for:

All Core Lightning v25.12 users (for payment crash fixes)
Anyone planning to create a new node (v25.12.1 is now stable)

Not affected but upgrade anyway:

Nodes created before v25.12 still use the old HSM format, so the signature bug doesn’t hit you. But you should upgrade for the payment crash fixes.

Core Lightning’s position in the Lightning ecosystem

Core Lightning (CLN) is one of four major Lightning Network node implementations. Developed by Blockstream and written in C, it’s known for spec-first development, modularity, and efficiency.

LND (Lightning Labs’ implementation) dominates with an estimated 70-90% of public Lightning nodes. Core Lightning is the primary alternative, favored by developers who prioritize spec compliance and customization. Other implementations include Eclair (ACINQ) and LDK (Spiral).

Multiple implementations matter because Lightning requires all nodes to speak the same protocol (defined by BOLT specs) to route payments across the network. No single vendor controls the protocol. Different codebases provide resilience against implementation-specific bugs.

However, this also means coordination challenges. Bugs like this one demonstrate both the friction of multi-implementation development and the importance of rigorous testing.

Timeline: 6 weeks from release to patch

December 4, 2025: v25.12 “Boltz’s Seamless Upgrade Experience” released with BIP-39/BIP-86 support
~6 weeks of user reports: GitHub issues filed for stuck funds and payment crashes
January 16, 2026: v25.12.1 “Boltz’s Seamless Upgrade Experience II” released
Time to patch: ~43 days from initial release to fix

The signature bug was diagnosed by user @rauaap and fixed by Core Lightning lead developer Rusty Russell. The payment crashes were reported by user michael1011.

The title “Boltz’s Seamless Upgrade Experience II” is tongue-in-cheek. Version 1 wasn’t so seamless.

What to do next

If you’re running Core Lightning v25.12, upgrade to v25.12.1 immediately. Here’s what to check after upgrading:

Test on-chain transactions: Withdraw a small amount to a test address to verify signing works
Back up your mnemonic (if you created a new node): Extract your 12 words with lightning-hsmtool getsecret ~/.lightning/bitcoin/hsm_secret and write them down securely
Monitor for further updates: Subscribe to Core Lightning releases

To check whether your node uses the old or new HSM format:

ls -lh ~/.lightning/bitcoin/hsm_secret
# Old format: exactly 32 bytes
# New format: larger (contains mnemonic data)

What this means for Lightning development

This bug is a reminder that cryptographic migrations require end-to-end testing. When address generation and signing code paths diverge, things break in subtle ways. The fact that users could diagnose and report the issue with stack traces and repro steps shows good open-source dynamics. Blockstream responded quickly.

The v25.12 release was ambitious: BIP-39 support, LSPS2 spec, xpay improvements, downgrade tool, performance boosts. Packing that much into one release increases risk. v25.12.1 feels like the “oops we shipped too fast” release.

BIP-39 adoption across Lightning is overdue. LND has had mnemonic support for years via aezeed (a custom format, not BIP-39). Standardizing on BIP-39 is the right move for interoperability, even if the transition was rocky.

Updated March 3, 2026