Electrum patches Lightning flaw, but old Bitcoin backups break

Electrum’s latest security update fixes a Lightning backup defect, but some Bitcoin wallet users still need to replace saved backups.

Older backups from wallets with non-deterministic Lightning keys lack information needed to reclaim funds from anchor channels, a Lightning channel type, after a remote close.

Version 4.8.2, dated Sept. 11, remains the latest release listed on Electrum’s official website as of Oct. 1.

The individual-backup fix adds payment-key information needed to claim the user’s balance from an anchor channel closed by the peer. Without that information, an affected backup lacks the key needed to sweep the output, meaning claim the coins on the Bitcoin blockchain.

Which wallets need attention?

Electrum’s release notes define two conditions that must coincide: the wallet has non-deterministic Lightning keys, and the backup concerns an anchor channel.

Read More:  Students Must Excel in Everything Alongside Sports: Prime Minister

Non-deterministic keys cannot be recreated from the wallet’s seed. The warning covers individual channel exports and exported full-wallet backups concerning Lightning recovery.

Lightning wallets based on BIP39 seeds or imported extended private keys (xprvs) always have non-deterministic Lightning keys. Electrum-seed wallets differ: their Lightning keys are deterministic when the wallet file was created in version 4.1 or later. Files created in 4.0.x do not qualify merely because the software is now newer.

On desktop, wallet information marks the Lightning channels as non-recoverable from the seed, while the channel-opening dialog warns that a channel cannot be recovered from the seed on Android. Anchor-channel use remains the additional condition for this backup defect.

Read More:  Splash patch leaves OADA liquidity problem unresolved

Related Reading

New Bitcoin proposal rescues locked multisig wallets – At a hidden cost

The individual-backup fix also hides the option to request a remote force-close when the backup cannot sweep the resulting output. The restriction keeps that backup from requesting a close whose output it cannot claim.