Twenty-one point eight kilobytes per hop. That is the fixed ciphertext payload a new post-quantum Lightning Network prototype bolts onto every gossip message a node relays. Stack it against a 10.2x increase in gossip download volume and an 8.8x jump in stored channel-graph data, and you get a migration bill that lands squarely on the smallest operators on the network. The research artifact surfaced this week as an unrefereed preprint. No author names. No institution disclosed. No audit trail. Just a feature-gated rust-lightning fork and a twelve-scenario compatibility matrix. The headline travels fast: Lightning can go quantum-safe. The fine print travels slower. The five surfaces it covers are all off-chain. The on-chain keys, commitment transactions, HTLC outputs and penalty transactions are exactly as quantum-vulnerable as they were before anyone wrote a line of this code.
The gap between those two sentences is where the entire story lives, and almost nobody reading the coverage will notice it.
Context: why a Lightning quantum patch is not the same as a Bitcoin quantum patch
Bitcoin has a quantum problem it has spent a decade arguing about without shipping a fix. The signature scheme underneath every spend is secp256k1, verified through ECDSA or Schnorr. Shor's algorithm eats that for breakfast once a cryptographically relevant quantum computer exists. Consensus changes to swap it out require a soft or hard fork, coordinated across miners, node operators, exchanges and custodians. That timeline is measured in years. Historically, in decades.
Lightning sits above that. It is a payment channel network, not a consensus system. Its upgrade path is a specification process called BOLT, maintained by a cross-implementation community, plus voluntary node upgrades. Nobody can be forced. Nobody can be blocked. That asymmetry is what makes the preprint worth reading at all.
The prototype targets five distinct off-chain surfaces: gossip, transport, invoices, offers and onion packets. Gossip is how nodes broadcast channel and node state. Transport is the encrypted peer-to-peer link. Invoices are BOLT 11. Offers are BOLT 12. Onion packets are the layered routing envelopes that hide payment paths. Every one of those touches cryptography that a future adversary could, in theory, record today and decrypt later.
The default configuration pairs ML-DSA-44 for signatures with ML-KEM-768 for key encapsulation. Both are NIST finalists-turned-standards under FIPS 204 and FIPS 203. Both sit at NIST security Level 3, roughly equivalent to AES-192. Not the cheapest tier. Not the ceiling either. A deliberate middle. The team chose margin over efficiency.
That choice tells you what kind of project this is. It is not optimizing for production. It is measuring the ceiling of cost.
Core: the bottleneck did not move where you think it moved
Here is the finding that should reframe every downstream conversation about this work. The preprint states plainly that communication, not raw cryptographic computation, dominates the results.
That single sentence kills the laziest objection to post-quantum migration. The standard line is that lattice-based cryptography is slow, that signatures are fat, that verification is expensive, that Bitcoin cannot afford it. The measured number argues otherwise. An ML-DSA-44 signature verification on a sixteen-core Threadripper completes in 327 microseconds. The authors explicitly warn against extrapolating that to end-to-end latency, and they are right, because the real cost is not on the CPU at all.
It is on the wire. And it is on the disk.
That is a fundamentally different engineering problem than the one the industry has been bracing for. Compute scales with hardware. Bandwidth and storage scale with money, and for a node operator, that money is recurring. Every month. Forever.
I learned this distinction the hard way in late 2017, when CryptoKitties ground the Ethereum mainnet to a halt and I sat watching gas prices blow past 500 Gwei while Dapper Labs quietly debated pausing the contract on Discord. The congestion was not a computation problem. It was a state-bloat and mempool problem. The block gas limit was fine. The network plumbing was not. This preprint is the same species of finding, wearing different clothes.
Now the numbers. Default configuration: gossip download volume up 10.2x, storage of graph data up 8.8x. Latency overhead per hop of 19 to 53 milliseconds on a 10 Mbit/s link, and 160 to 187 milliseconds on a 1 Mbit/s link. That fixed 21.8-kilobyte ciphertext list rides along on every hop.
Run the multi-hop arithmetic yourself, because the preprint deliberately does not. A typical Lightning payment traverses five to ten hops. At the slow-link figure, a five-hop path absorbs roughly 0.8 to 0.95 seconds of added latency. A ten-hop path, 1.6 to 1.9 seconds. I want to be precise here: that is my extrapolation, not the paper's conclusion, and real end-to-end latency depends on path selection, node uptime and liquidity distribution. But the order of magnitude is enough to matter. Lightning's entire pitch is instant settlement. Sub-second is the brand. Add two seconds and you have a different product.
The storage finding compounds worse. That 21.8-kilobyte overhead is fixed per hop, but the channel graph is not fixed. It grows. Historically, monotonically. Combine a constant per-hop payload with a growing graph and you get linear amplification of absolute data volume. The storage floor for running a node rises in perpetuity, not once.
Now the piece that deserves far more attention than it is getting.
The authors describe the design as hybrid: classical and post-quantum cryptography running side by side, with a fail-close fallback. Read that carefully. Fail-close means that if negotiation of the post-quantum parameters fails, the connection terminates rather than silently reverting to weaker protection.
That is the correct security choice. It is also a new attack surface. An adversary who can force a parameter negotiation to fail can force a disconnection. In a payment channel, forced disconnection means failed payments and, at the extremes, forced channel closures. You do not need to break the lattice math to hurt this network. You just need to be able to break a handshake. Downgrade-adjacent denial of service at a fraction of the cost of cryptanalysis.
The preprint does not dwell on this. I am flagging it because payment channels punish availability failures more brutally than they punish confidentiality failures. A dropped payment is a user-visible event. A silently weakened cipher suite is not.
Then there is the standards-scissors problem, and this is the part that should worry anyone modeling a migration roadmap.
The best-performing variant tested uses FN-DSA, the Falcon-lineage scheme. It cuts overhead to 4.2x instead of 10.2x. A more than twofold improvement on the single most expensive metric in the entire study. There is one catch. NIST has not finalized FN-DSA. It remains in development, not a published standard.
So the situation is this. The best available performance sits behind a standard that does not exist yet. The best available standard carries roughly 2.4x the cost. That is a genuine scissors gap, and it does not close on the researcher's schedule. It closes on NIST's, or it does not close at all.
Which means the practical constraint here was never cryptography. It was never even performance. It is the coordination calendar of a third party that has no obligation to this network whatsoever.
One more boundary the preprint draws itself, and it matters more than the compatibility matrix it ships alongside. The team validated twelve scenarios demonstrating binary coexistence, meaning post-quantum nodes and classical nodes can share a network. Good. Then they explicitly state that compatibility does not establish network-wide readiness, and that testing against other Lightning implementations was deferred.
Only rust-lightning was tested. Lightning Dev Kit. The Spiral-backed, Block-funded Rust implementation. LND, Core Lightning and Eclair were not touched.
Lightning is a cross-implementation interoperability protocol. A single implementation is a fraction of the node population. Validating one fork proves feasibility, not compatibility. Every other implementation must reimplement the same path independently, and then all of them must agree on wire format through the BOLT process, which has historically moved at the pace of consensus-building among proud, opinionated maintainers.
This is the most complex coordinated upgrade in Lightning's history, and it has been demonstrated on maybe a fifth of the network.
Now the economics, which is where the preprint gets refreshingly honest.
The authors list, among the difficult operational questions raised by their own experiments, how much additional gossip, storage and payment traffic node operators can actually absorb. That is not a footnote. That is the whole ballgame, stated by the people who built the thing.
Lightning has no token subsidy. Node operators run on routing fees plus whatever they earn on self-funded liquidity. If bandwidth and storage costs rise structurally while routing revenue stays flat, the economic viability of small and mid-sized nodes erodes. Not dramatically. Gradually. Which is how decentralization dies, when it dies at all, in infrastructure networks.
I spent the 2020 DeFi Summer treating protocol docs like IKEA manuals, deploying real capital on Uniswap and Curve to feel slippage and impermanent loss in my own balance sheet rather than reading about them, and I caught a discrepancy in Curve's initial emission schedule that way. The lesson transfers. You do not understand a network's cost structure by reading a whitepaper. You understand it by watching who can afford to keep participating.
If only data-center-grade operators can absorb a 10.2x gossip load and an 8.8x storage load, Lightning drifts toward a mining-pool-shaped geography. Permissionless in protocol. Concentrated in practice. Same structure, different layer.
Contrarian: the timeline runs backwards from what everyone assumes
Everyone frames quantum risk as a future problem. Distant, abstract, someone else's decade. This preprint implies the opposite ordering, and the implication is buried rather than stated.
Privacy exposure is happening now. Onion routing metadata and gossip traffic can be harvested today by any passive observer with a tap and a hard drive. Harvest now, decrypt later is not a hypothetical. It is an active, ongoing, irreversible collection process. The moment those packets leave a node, the clock starts and cannot be reset.
Funds exposure is a future problem. It requires a cryptographically relevant quantum computer that does not yet exist, and it requires someone to actually point it at Bitcoin.
So the correct prioritization is inverted from the instinct. Privacy protection is urgent. Funds protection is eventually-important. The article headline captures this with accidental precision: Bitcoin may go quantum-safe, Lightning privacy stays exposed. Everyone reads the second clause as bad news about Lightning. Almost nobody reads it as a statement about which threat arrives first.
There is a second inversion worth sitting with, and it is uncomfortable. Partial safety can be more dangerous than no safety at all.
This prototype protects gossip, transport, invoices, offers and onion packets. It does not protect on-chain keys, commitment transactions, HTLC outputs or penalty transactions. In other words, it protects the messages and not the value. A user who reads that Lightning went post-quantum and concludes their money is quantum-safe has been misled by their own optimism. The communication layer is hardened. The vault door is untouched. A half-protected system that announces itself loudly is a worse posture than an unprotected system that nobody trusts with anything important.
And there is the paradox the coverage will not touch at all. A security upgrade that prices out small node operators produces a security downgrade. Fewer nodes, less path diversity, weaker censorship resistance. The cryptography gets stronger and the network gets softer in the same motion.
Takeaway
Watch three things. The BOLT specification repositories, to see whether a post-quantum wire format ever becomes a cross-implementation proposal rather than a single-fork experiment. The NIST FN-DSA timeline, because the difference between 4.2x and 10.2x overhead is the difference between a migration and a schism. And the Lightning node count, because the honest question at the end of this paper is not whether the cryptography works. It is who can still afford to run the network once it does. The math is ready. The budget is not.