Anchor Channels

Electrum developers closed a Lightning Network backup flaw that left some Bitcoin wallet users unable to reclaim funds after a channel closed remotely, but the fix does not retroactively repair backups already saved to disk. For institutional holders running self-custodied Lightning infrastructure, the episode is a reminder that off-chain key management carries recovery risks that standard custody audits rarely test.

• Electrum 4.8.2, dated Sept. 11, remains the newest build listed on Electrum’s official site as of Oct. 1.
• Wallets using BIP39 seeds or imported extended private keys always generate non-deterministic Lightning keys and stay at risk.
• Electrum-seed wallets are only safe if the wallet file was created in version 4.1 or later, not merely upgraded to it.

• 4.8.2 patched Electrum release, still current three weeks after shipping
• Sept.11 release date of the fix, versus Oct.1 confirmation it is current
• v4.1 wallet-file version threshold separating safe from vulnerable seeds

Electrum’s development team merged a fix for a backup defect in its Lightning Network integration, according to the pull request on the wallet’s GitHub repository. Lightning is Bitcoin’s off-chain payment layer that lets users transact without posting every payment to the base blockchain, and anchor channels are a Lightning channel type designed to let either party adjust fees when closing a channel. The defect meant that if a peer force-closed an anchor channel remotely, certain saved backups lacked the private-key material needed to sweep the user’s share of the balance back onto the Bitcoin chain.

The fix shipped in Electrum 4.8.2, released Sept. 11, still the newest build on Electrum’s official website as of Thursday, Oct. 1. It does not rewrite old backups automatically.

The gap was first detailed by CryptoSlate, which traced the fix to two linked pull requests and Electrum’s own warning language for affected wallets.

PR 10851 Adds Missing Payment-Key Data to Channel Backups

The pull request extends Electrum’s channel backup format to include the payment_basepoint, the key material needed to claim an anchor channel’s to_remote output after the peer force-closes it. Without that field, an exported backup could record that funds existed in a channel but lacked the specific key required to sweep them.

The fix also hides the option to request a remote force-close whenever the backup on hand cannot sweep the resulting output, preventing a user from triggering a close their own backup cannot settle.

A companion change, PR 10851, repairs full wallet-file exports. Maintainer SomberNight noted in the pull request discussion that earlier exports deleted a randomly generated Lightning private key, so re-enabling Lightning from that backup would generate different keys entirely, leaving the old channel records useless for spending anchor-channel funds.

BIP39 and Imported-Key Wallets Carry the Permanent Risk

Electrum’s release notes set two conditions that must both apply for a backup to be affected: the wallet uses non-deterministic Lightning keys, and the backup involves an anchor channel. Wallets built from BIP39 seeds or imported extended private keys always fall into the non-deterministic category, because those keys cannot be regenerated from the seed the way Electrum’s native format allows.

Electrum-seed wallets are the exception, but only partially. Their Lightning keys are deterministic solely if the wallet file was created in version 4.1 or later; a file originally generated under 4.0.x stays non-deterministic no matter how many times the software itself is upgraded.

On desktop, Electrum’s wallet information panel now flags channels as non-recoverable from the seed, while the Android app warns in its channel-opening dialog before a user even funds a channel.

The distinction did not exist in earlier releases, where the seed was broadly assumed to regenerate all wallet keys, including Lightning ones. It leaves one question Electrum’s documentation does not resolve: users who have already discarded the original wallet file that produced an at-risk backup have no stated path back to a safe export.

Startup Warnings Push Users Toward Manual Re-Export

Electrum 4.8.2 fixes the backup logic for future exports, but it cannot repair files generated before the update. The documented remedy is a fresh export from the running wallet, and Electrum now displays a startup warning to any wallet it detects as affected under the two conditions above.

That remedy depends on still holding the original wallet data needed to generate a new export. Installing 4.8.2 changes the software, but it does not recover key material already lost along with deleted wallet files.

The CCS read. The bug matters less for its scale than for what it says about Lightning tooling broadly: recovery assumptions baked into seed phrases do not automatically extend to off-chain layers, a gap custodians building institutional Lightning rails, and projects pursuing related upgrades like post-quantum Lightning changes, will need to account for in their own backup audits.

Electrum has not said whether a future release will attempt to identify which specific users still hold funds in anchor channels opened before the Sept. 11 patch, leaving the re-export step entirely manual and voluntary, much as node operators faced after unrelated client updates like Geth’s v1.17.7 release required opt-in configuration changes rather than automatic fixes.