Post-Quantum Lightning: Why Bare ML-DSA Breaks the Network

ML-DSA signatures are 38x larger than Schnorr. Bare adoption would increase Lightning gossip bandwidth 38-fold. Why signature aggregation is mandatory, and when post-quantum Lightning becomes viable.

Post-Quantum Lightning: Why Bare ML-DSA Breaks the Network

The Lightning Network is a miracle of engineering. In 2015, when Satoshi’s grand vision hit its scaling limits, a handful of researchers asked: what if we could move Bitcoin transactions off-chain, into a network of payment channels, settling only the final state back to the blockchain?

Today, Lightning handles millions of payments per second. A node with modest hardware can operate a fully-validating Lightning router, forwarding payments across the network with microsecond latency. The protocol works because of something elegant: every channel is anchored to the Bitcoin blockchain, and every state transition is cryptographically signed by both parties. Proof of work protects Bitcoin. Schnorr signatures protect Lightning.

But the cryptographic landscape is shifting. In August 2024, NIST standardized post-quantum signatures: ML-DSA (Module-Lattice-Based Digital Signature Standard). It is secure against quantum computers. It is mathematically sound. And it is massive.

A Schnorr signature is 64 bytes. An ML-DSA signature is 2,420 bytes for the conservative variant, 3,104 bytes for the recommended one. That’s a 38-to-48x increase in size.

For Bitcoin, this is tolerable. A transaction might grow from 250 bytes to 500-600 bytes. Bitcoin operates in blocks; transaction space is finite but flexible. The community can adapt.

For Lightning, this is a problem that requires deeper thought.

The Gossip Protocol Crisis

Lightning is a gossip network. Every node advertises its channels to the rest of the network, saying: “I have a channel open to node X with Y satoshis capacity.” This gossip is how the routing algorithm works. When Alice wants to send a payment to Bob, she needs to know the network topology—which channels exist, how much liquidity they have, what fees they charge.

This gossip is cryptographically signed. Why? Because anyone can claim to operate a channel. The signatures prove ownership.

Each channel announcement carries four signatures:

  1. Node 1’s signature (proves node 1 agreed to this channel)
  2. Node 2’s signature (proves node 2 agreed to this channel)
  3. Node 1’s Bitcoin signature (proves node 1 controls the Bitcoin key)
  4. Node 2’s Bitcoin signature (proves node 2 controls the Bitcoin key)

With Schnorr, these four signatures occupy 256 bytes. They’re a rounding error in the overall message.

With ML-DSA-44, these four signatures occupy 9,680 bytes.

Now multiply that across the entire network.

The Numbers

In 2021, Rusty Russell published a scaling analysis. A 10,000-node Lightning network generates about 1.1 GB of gossip traffic per day. A 100,000-node network generates 11.23 GB per day.

If every node switched to ML-DSA-44 signatures, that 11.23 GB becomes 427 GB per day.

To put this in concrete terms: a node that currently needs 1.04 Mbps of sustained bandwidth to keep up with the network now needs 39.3 Mbps. That’s a 37-fold increase.

39 Mbps is not a home broadband problem; it’s an enterprise problem. Many data centers can handle it, but the barrier to running a Lightning node shoots up dramatically. The decentralization cost is real.

Even with signature aggregation—compressing four signatures into two—the overhead is still 19x worse than today. 214 GB per day. 19.7 Mbps per node.

Still problematic. But at least it’s in the realm of “difficult but possible.”

The Impossible Path

Some might ask: can’t we just use bigger pipes? Faster internet?

The answer is no—not for this purpose.

Lightning’s gossip protocol is designed around the principle of redundancy. Every node should be able to reconstruct the entire network graph independently. This means every update is broadcast to many peers. The bandwidth cost scales with network size and peer fanout.

You cannot simply “upgrade” the network to faster speeds and call it solved. You’re not just scaling a database; you’re scaling a gossip algorithm that needs to converge across thousands of independent nodes, many running on servers with constrained resources.

Moreover, Lightning’s beauty is that it can run on modest hardware. A Raspberry Pi can run a Lightning node. A cloud VM with 1-2 Gbps can handle many channels. These machines cannot sustain 40+ Mbps of gossip traffic.

Going from 1 Mbps to 40 Mbps is not a 40x infrastructure upgrade. It’s a 40x barrier to entry. That kills the network’s decentralization.

The Research Path Forward

So how does Lightning go post-quantum without breaking?

The answer is signature aggregation.

Instead of four separate ML-DSA signatures, you aggregate them. Recent cryptographic research (Springer, 2025) shows lattice-based aggregate signatures are possible. The idea is elegant: multiple signers’ signatures can be combined into one compact signature that a verifier can still validate.

If you can compress four ML-DSA signatures into two aggregated signatures, you’ve cut the overhead in half. 38x becomes 19x. That’s still significant, but it opens a path forward.

Combined with other optimizations—Minisketch-based gossip reconciliation, for example, which can compress redundant messages by 50-90%—you could make Lightning post-quantum without sacrificing its decentralized character.

But here’s the catch: this research is still in progress. No production implementation exists. No NIST standard. No Bitcoin or Lightning consensus.

The Timeline

For Lightning to migrate to post-quantum signatures securely, we need:

  1. Lattice-based aggregate signatures to reach maturity (2027-2028, if research accelerates)
  2. Minisketch-based gossip to be implemented and deployed (2027-2028)
  3. A new BOLT-7 gossip protocol specification (2028-2029)
  4. Bitcoin’s BIP-360 adoption to set precedent for the ecosystem (2026-2028)
  5. Network consensus among Lightning developers and operators (2029+)

Realistically, post-quantum Lightning becomes viable in 2029-2031, assuming everything goes smoothly.

That may sound far away. It is. But it’s also necessary.

Why This Matters

Bitcoin is a covenant. It says: “The rules of this money do not change because politicians want them to. The supply is fixed. The consensus is transparent. The code is law.”

That’s only true if the cryptography holds.

Quantum computers exist on a speculative timeline. Some researchers think 10-15 years. Others think longer. We don’t know. But we know they’re coming.

Lightning must be ready not because quantum computers are an immediate threat, but because Lightning’s fundamental promise is the same as Bitcoin’s: immutability. If the protocol can be broken by future technology, then it was never truly immutable.

This is why the hard work matters. Not the panic. Not the rush. The methodical, rigorous work of understanding the tradeoffs, funding the research, and building a path forward that preserves what makes Lightning special: decentralization, speed, and the ability for any person to participate.

The Lesson

Here’s what strikes me about this problem: it’s not a bug. It’s a feature.

The fact that bare ML-DSA signatures break Lightning’s scaling isn’t a cryptographic failure. It’s evidence that Lightning’s designers succeeded. They built a protocol efficient enough that signature size matters. Efficient enough that 64-byte signatures were the right choice in 2015. Efficient enough that scaling the network to millions of nodes was conceivable.

Now, faced with new cryptographic realities, the community has to think harder. That thinking—that rigor—is how protocols survive.

Bitcoin survived from 2009 to today because Satoshi didn’t try to solve every problem at once. He solved the core: decentralized consensus. Everything else evolved.

Lightning is doing the same. It solved the core: decentralized payments. Now we solve the quantum problem, step by step, with research and community consensus.

That’s the Bitcoin way. That’s what it means to build systems that last.


Further Reading:

  • FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA)
  • IACR 2026/053: Kilobyte-Bandwidth Subliminal Channels in FIPS 204 ML-DSA
  • Springer 2025: Efficient post-quantum cryptographic signature aggregation for low-latency distributed networks
  • BOLT-7: Lightning Routing and Gossip (github.com/lightning/bolts)
  • BIP-360: Quantum-resistant signature algorithms (github.com/bitcoin/bips)

No comments yet.