Hybrid post-quantum Lightning, implemented in rust-lightning
Post-Quantum Lightning Network
PQLN protects the off-chain surfaces of Bitcoin's Lightning Network against quantum adversaries. It adds ML-DSA and ML-KEM beside the existing cryptography, needs no change to Bitcoin, and works alongside today's nodes.
01The threat
Harvest now, decrypt later
An adversary records Lightning's encrypted traffic today and stores it.
Once a quantum computer exists, Shor's algorithm recovers the secp256k1 keys behind every recorded handshake.
The recorded sessions then open, and every payment inside them becomes readable.
02The scope
What can move today
The keys behind channel funds live inside Bitcoin transactions, so they wait for a Bitcoin consensus change.
Everything else lives in messages between Lightning nodes, so a software update can protect it.
PQLN protects all five of these off-chain surfaces.
03BOLT 7Gossip
Keys travel by gossip
Lightning has no certificate authority, so every node announces its ML-DSA and ML-KEM keys in its node_announcement.
Every PQLN node pins these keys on first sight.
A forged announcement with substituted keys does not match the pin, so the node rejects it.
- 27 · 29 · 31
- TLV records
- +4928 B
- per announcement
- +2424 B
- per channel update
04BOLT 8Transport
A hybrid handshake
In act one, the initiator encapsulates to the responder's pinned ML-KEM key, so only the real responder can finish the handshake.
In act two, the responder encapsulates to a fresh ephemeral key, which gives forward secrecy.
Act three stays unchanged, and the session keys now depend on five shared secrets.
- 2322 B
- act one, from 50
- 1138 B
- act two, from 50
- Own port
- no negotiation
05BOLT 11Invoices
A signature in four fields
An ML-DSA-44 signature is 2420 bytes, but a BOLT 11 tagged field holds at most 639.
PQLN splits the signature across four tagged fields, and vanilla decoders skip them as unknown fields.
The invoice grows to 4286 characters and still fits in one QR code, with 10 characters to spare.
- Tag 22
- four fields
- 4286
- characters
- 4296
- QR code limit
06BOLT 12Offers
The offer is the anchor
An offer's payee often hides behind a blinded path, so gossip never shows its keys.
PQLN commits a fresh ML-DSA key in every offer, and the payer records that key.
The returned invoice must verify under exactly that key before any HTLC goes out.
- Per offer
- fresh ML-DSA key
- 2528
- offer characters, from 416
- Async
- static invoices too
07BOLT 4Payment onion
Twenty slots
One 1088-byte ML-KEM ciphertext would nearly fill the 1300-byte onion, so the onion keeps its format and only its per-hop secrets turn hybrid.
The ciphertexts ride beside the onion in a list of 20 slots, and dummies shaped like real ciphertexts fill the rest.
Each hop opens the front slot and rotates it to the back, so no hop can count the real entries or learn the route length.
- 1300 B
- onion, unchanged
- 21.8 kB
- for all 20 slots
- Fail closed
- on any tampering
08The cost
Bandwidth, not compute
The new cryptography is cheap. ML-DSA signing is the slowest new operation, and it takes 0.33 ms.
On a link with a 50 ms round trip at 10 Mbit/s, a payment gets 19 to 53 ms slower per hop.
Gossip carries the real cost, since a new node downloads about 10 times as much data, or about 4 times with FN-DSA-512.
09Interoperability
Nothing got stuck
Between PQLN nodes, a payment runs fully protected.
When a vanilla node sits on the route, the payment falls back to classical and still completes.
With a require flag on, the node refuses that downgrade before any HTLC moves.
- 12 / 12
- scenarios passed
- 0
- stuck payments
- Today
- no coordinated upgrade
10Paper and code
Read the paper.
Run the code.
Open problem: a pin only protects two nodes that met before a quantum computer exists, and the paper sketches how to close this gap without a consensus change.
git clone https://github.com/ahmet-kurt/pq-rust-lightning
cd pq-rust-lightning
cargo test -p lightning --lib --features post-quantum