The Lightning Network isn’t ‘helplessly broken’

A post from Udi Wertheimer a few weeks ago made headlines across crypto media with a stark claim: the Lightning Network is “helplessly broken” in a post-quantum world, and its developers can do nothing about it. The headline traveled fast. For businesses that have built real payment infrastructure on Lightning or are evaluating it, the implications were unsettling.

It deserves a measured response.

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.

This is a real and specific vulnerability. But it is a timed race against an attacker who must actively solve one of the hardest mathematical problems in existence, within a fixed window, for each individual output they want to steal. It is not a passive, silent drain on every Lightning wallet simultaneously.

The quantum hardware reality check

Here is the part that rarely makes it into the headlines: cryptographically relevant quantum computers do not exist today, and the gap between where we are and where we would need to be is enormous.

Breaking Bitcoin’s elliptic curve cryptography requires solving the discrete logarithm on a 256-bit key, a roughly 78-digit number, using millions of stable, error-corrected logical qubits running for an extended period. The largest number ever factored using Shor’s algorithm on actual quantum hardware is 21 (3 × 7), achieved in 2012 with significant classical post-processing assists. The most recent record is a hybrid quantum-classical factoring of a 90-bit RSA number, impressive progress, but still roughly 2⁸³ times smaller than what it would actually take to break Bitcoin.

Google’s quantum research is real and worth watching. The timelines discussed by serious researchers range from optimistic estimates for the late 2020s to more conservative projections for the 2030s or beyond. None of that is “your Lightning balance is at risk today.”

The development community is not sitting still

Wertheimer’s framing, that Lightning developers are “helpless”, is also out of step with what is actually happening. Since December alone, the Bitcoin development community has produced more than five serious post-quantum proposals: SHRINCS (324-byte stateful hash-based signatures), SHRIMPS (2.5 KB signatures across multiple devices, roughly three times smaller than the NIST standard), BIP-360, Blockstream’s hash-based signatures paper, and proposals for OP_SPHINCS, OP_XMSS, and STARK-based opcodes in tapscript.

The correct framing is not that Lightning is broken and unfixable. It is that Lightning, like all of Bitcoin, and like most of the internet’s cryptographic infrastructure, requires a base-layer upgrade to become quantum-resistant, and that work is underway.

What this means for businesses building on Lightning today

Lightning processes real payment volume for real enterprises today, iGaming platforms, crypto exchanges, neobanks, and payment service providers moving money globally at fractions of a cent with instant finality. The question businesses should be asking is not whether to abandon Lightning based on a theoretical future threat, but whether the teams building Lightning infrastructure are paying attention to what is coming and planning accordingly.

The answer, based on the volume and quality of post-quantum research happening in the Bitcoin development community right now, is yes.

The Lightning Network is not helplessly broken. It faces the same long-horizon cryptographic challenge as the entire digital financial system, and it has a development community actively working to address it. That is a different story from the one the headline told.