The Lightning Network isn’t ‘helplessly broken’
Shell argues the network is fixable and proposes a different framing to the recent quantum debate.
Wertheimer is a respected Bitcoin developer, and his underlying concern is legitimate: quantum computers, if they ever become sufficiently powerful, pose a real long-term challenge to the cryptographic systems on which Bitcoin and Lightning depend. That part is true, and the Bitcoin development community is already working on it seriously. But the framing of Lightning as “helplessly broken” obscures more than it reveals, and businesses making infrastructure decisions deserve a clearer picture.
What Wertheimer got right
Lightning channels require participants to share public keys with their counterparty when opening a payment channel. In a world where cryptographically relevant quantum computers (CRQCs) exist, an attacker who obtains those public keys could theoretically use Shor’s algorithm to derive the corresponding private key, and from there, steal funds.
This is a real structural property of how Lightning works. What the headline leaves out
The threat is far more specific and far more conditional than “your Lightning balance can be stolen.”
First, the channels themselves are protected by a hash while they are open. Funding transactions use P2WSH (Pay-to-Witness-Script-Hash), meaning the raw public keys inside the 2-of-2 multisig arrangement are hidden onchain for as long as the channel remains open. Lightning payments are also hash-based, routed through HTLCs (Hashed Time-Lock Contracts), which rely on hash preimage revelation rather than exposed public keys. A quantum attacker passively watching the blockchain cannot see the keys they would need.
The realistic attack window is much narrower: a force-close. When a channel is closed, and a commitment transaction is broadcast onchain, the locking script becomes publicly visible for the first time, including the local_delayedpubkey, a standard elliptic-curve public key. By design, the node that broadcasts it cannot immediately claim its funds: a CSV (CheckSequenceVerify) timelock, typically 144 blocks (about 24 hours), must first expire.
In a post-quantum scenario, an attacker watching the mempool could see that a commitment transaction confirms, extract the now-exposed public key, run Shor’s algorithm to derive the private key and attempt to spend the output before the timelock expires. HTLC outputs at force-close create additional windows, some as short as 40 blocks, roughly six to seven hours.
