Lightning developer proposes post-quantum cryptography upgrade for offchain layers
Bitcoin Optech’s newsletter #424 covers a proposal from developer Ahmet Kurt to rebuild the Lightning Network’s offchain messaging layers around post-quantum cryptography. The design, called PQLN, touches gossip, transport, invoices, offers and onion routing but leaves onchain consensus rules untouched.
- PQLN swaps in ML-DSA and ML-KEM keys across BOLT7, BOLT8, BOLT11, BOLT12 and BOLT4
- A PQLN node must download 10 times and store 9 times the data of a classical LN node
- Feature bits, TLV types and gossip-relay limits for PQ messages are not yet assigned
- 10x extra data a PQLN node must download versus a classical node
- 9x extra data a PQLN node must store versus a classical node
- 0.33 ms time for the most expensive PQLN operation, ML-DSA signing
The proposal, posted to Delving Bitcoin and summarized in Bitcoin Optech Newsletter #424, builds on layer-by-layer post-quantum analysis the newsletter first covered in issue #408. Kurt and collaborators published a paper alongside a working implementation based on rust-lightning. No changes touch onchain operations, since Kurt notes that would require a consensus change.
Gossip and Transport Get New Keys
Under PQLN, the node_announcement message in BOLT7 gossip carries a node’s ML-DSA and ML-KEM public keys plus an ML-DSA signature, and channel_update carries only the signature. Keys are pinned so a node can reject substitution attempts.
The channel_announcement message stays unmodified. The newsletter quotes the reason directly: “the channel_announcement message has not been modified, since the message would be half-forgeable due to the fact that two of its four signatures are made with the onchain funding keys.” Transport, per BOLT8, moves to a hybrid Noise handshake using two ML-KEM encapsulations, one to the pinned static key and one to a fresh ephemeral key for forward secrecy, with no in-band negotiation.
Invoices Split Signatures, Onion Adds Dummy Slots
A BOLT11 tagged field holds at most 639 bytes, so a 2,420-byte ML-DSA-44 signature must be split across four fields. BOLT12 offers commit a fresh ML-DSA key per offer, and payers check the invoice against that key before sending an HTLC.
Because an ML-KEM ciphertext is too large for an onion packet, PQLN keeps the BOLT4 onion format and instead makes the Sphinx secret hybrid. Ciphertexts travel with the onion in update_add_htlc across 20 slots, with unused slots filled by dummy ciphertext to hide route length.
Bandwidth, Not Compute, Is the Cost
Kurt tested interoperability on regtest. PQLN nodes fell back to the classical protocol when a classical node sat on the payment route, or failed before sending any HTLC when a require-PQ flag was set.
Compute overhead is minor; the newsletter states the most expensive operation, ML-DSA signing, takes only 0.33 ms. The real cost, according to Kurt, is bandwidth: a PQLN node needs to download 10 times and store 9 times the data of a simple LN node.
What the Proposal Does Not Settle
The newsletter lists open problems Kurt flagged without resolving. Pinning only protects nodes that met before a cryptographically relevant quantum computer existed. The 1,024-byte MAX_EXCESS_BYTES_FOR_RELAY limit in rust-lightning currently prevents non-PQ nodes from relaying PQ gossip, and feature bits and TLV types for PQLN messages have not been assigned.
The document does not say when, or whether, any BOLT specification body will adopt PQLN, nor does it give a timeline for mainnet deployment.
What Changes for Node Operators
Nothing changes yet for anyone running Core Lightning or LDK today. PQLN exists as a proposal and a regtest implementation, not a merged BOLT change, so no operator needs to upgrade or reconfigure a node because of it.
What it does establish is a concrete bandwidth tradeoff for a post-quantum Lightning path: roughly tenfold more download and ninefold more storage per node.
The CCS read. A 10x bandwidth tax for post-quantum Lightning is a routing-node problem before it is a user problem, and it will filter who can afford to run a PQ-capable node long before any wallet asks a holder to move funds.
Watch for feature-bit and TLV-type assignments for PQLN messages, and for whether rust-lightning maintainers raise the MAX_EXCESS_BYTES_FOR_RELAY limit that currently blocks non-PQ nodes from relaying PQ gossip.
