Post-quantum Lightning: what PQLN protects, and the box it cannot close

Updated September 2026

This week's Bitcoin Optech newsletter led with a proposal to make the Lightning Network quantum resistant. It is the first one that comes with an implementation and measurements on real nodes. It is also careful about its limits, and those limits are the useful part for anyone who keeps coins in channels. Here is what it changes, what it leaves alone, and where the box sits in all of it.

What is PQLN?

PQLN was posted to Delving Bitcoin on September 16, 2026 by Ahmet Kurt, a researcher at East Texas A&M University. The paper, "PQLN: Post-Quantum Security for the Bitcoin Lightning Network's Off-Chain Surfaces", appeared on arXiv on September 12, with coauthors Abdul-Salem Beibitkhan, Yacoub Hanna and Abdullah Aydeger. The code is a fork of rust-lightning, the library behind LDK, that adds about 11,000 lines behind a post-quantum build option.

The design is hybrid. It keeps every classical elliptic curve operation and adds two NIST standards next to them: ML-DSA-44 for signatures and ML-KEM-768 for key exchange. If the new schemes turn out to be weak, the old ones still hold. If a quantum computer breaks the old ones, the new ones still hold. That matches the direction Olaoluwa Osuntokun sketched in a layer-by-layer post in June, which suggested keeping elliptic curve cryptography running in parallel because the post-quantum schemes are young.

The new keys come from the node's existing seed, at two hardened BIP 32 derivation indices. The paper points out two consequences. The seed backup that restores a node's classical identity restores its post-quantum identity too. And because hardened derivation runs one way only, a quantum attacker who recovers the classical node key learns nothing about the post-quantum keys made from the same seed.

Why can Lightning move before Bitcoin does?

Changing how Bitcoin checks signatures needs a consensus change that every full node enforces. That is the road BIP-360 and the SHRINCS signature drafts are on, and it is slow.

Most of Lightning is not on the chain at all. Nodes find each other through gossip, talk over their own encrypted connections, request payments with invoices and route them through onions. All of that is messages between nodes, and Lightning's message formats let a node add new fields that older software skips as unknown data. So an upgraded node can speak post-quantum to other upgraded nodes and plain Lightning to everyone else.

The paper's argument for doing this now is the same one the EU supervisors made last week: harvest now, decrypt later. The paper says an adversary "can already record Lightning's encrypted traffic today and decrypt it once such a computer exists." A recorded session cannot be re-encrypted after the fact. Only traffic sent with post-quantum protection from the start is safe from that.

What PQLN changes, layer by layer

Lightning's rules are written as numbered specifications called BOLTs. PQLN touches five of them. The table sums up what each one does and what the paper changes.

Gossip. Lightning has no certificate authority, so the paper distributes the new keys through gossip itself. A node's announcement carries its ML-DSA and ML-KEM public keys plus an ML-DSA signature. Every other node pins those keys the first time it sees them and rejects any later announcement that swaps them out.

Transport. The connection between two nodes starts with a Noise handshake built on three elliptic curve Diffie-Hellman exchanges. PQLN adds two ML-KEM encapsulations: one to the other node's pinned key, which proves who it is, and one to a fresh key made for that session, which gives forward secrecy. The hybrid handshake runs on its own port with no negotiation message, because, as Kurt put it on Delving, a negotiation message "is exactly the kind of thing a quantum adversary could rewrite to force a downgrade."

Invoices. This is where size bites. A BOLT 11 tagged field holds at most 639 bytes, and an ML-DSA-44 signature is 2,420 bytes, so PQLN splits it across four fields. A normal invoice is around 400 characters. A PQLN invoice carrying only the new signature is 4,286 characters, which fits the largest alphanumeric QR code, 4,296 characters, with 10 to spare.

Offers. Nodes behind BOLT 12 offers are often unannounced, so gossip pinning does not help. The offer carries its own anchor: a fresh ML-DSA key for each offer, and the payer checks the returned invoice against that exact key before any money moves.

Onions. An ML-KEM ciphertext is 1,088 bytes and the onion packet is 1,300, so the ciphertexts cannot go inside it. PQLN leaves the onion's format alone and sends the ciphertexts next to it in a fixed list of 20 slots, the maximum route length. Unused slots hold dummies built to look exactly like real ciphertexts, so a routing node cannot count them and learn how long the route is.

What PQLN does not touch: the coins

A Lightning channel is money on the Bitcoin chain. Opening one means a funding transaction that locks coins in an output both parties control. Every payment updates a pair of commitment transactions. Closing broadcasts the latest one, and cheating with an old one lets the other side take everything with a penalty transaction. The paper says it plainly: "All three are ordinary Bitcoin transactions, so the safety of the funds inside a channel rests on Bitcoin's own cryptography."

So PQLN puts BOLTs 2, 3 and 5, the specifications that build and handle those transactions, out of scope. Its threat model lists "the theft of channel funds by breaking the secp256k1 keys of funding, commitment or HTLC outputs" as something no Lightning-level change can prevent. That waits for Bitcoin's own post-quantum transition.

A post-quantum Lightning node protects what nodes say to each other. The coins in its channels are exactly as exposed as they were the day before the upgrade.

Where is the box in a Lightning channel?

This site's rule is simple: a public key on the chain is an open box, and a hash is a closed one. A channel's funding output is a 2-of-2 multisig inside a P2WSH output. On the chain, that shows only a hash of the script, the same closed shape as any never-spent multisig address. The two public keys appear on the chain when the channel closes and the output is spent.

Gossip changes that for public channels. To put a channel on the network map, both nodes sign a channel_announcement, and the BOLT 7 specification requires that message to carry bitcoin_key_1 and bitcoin_key_2, the two funding public keys, so other nodes can check that the P2WSH output really pays to them. Every node that downloads the graph gets a copy.

So a public channel's box is open for as long as the channel is open. The hash on the chain is closed, but the keys that open it are published, the same way address reuse publishes a key while coins still sit behind it. In long and short exposure terms, that is long exposure. The attacker does not need to race anything. The keys are there for as long as the channel stays open.

This is also why PQLN leaves channel_announcement classical. Two of its four signatures are made with those funding keys, which the paper says "prove ownership of the on-chain funding output and cannot be protected off-chain." Protecting only the other two would leave a message a quantum attacker could still half forge.

Unannounced channels, which never enter the public map, do not broadcast their funding keys in gossip. Their counterparty knows the keys, but the network at large does not until the channel closes.

What does it cost?

Not processing time. In the authors' measurements the slowest new operation, ML-DSA signing, took 0.33 milliseconds, about 13 times slower than an ECDSA signature and still negligible. Over a simulated link with 50 ms of round-trip latency and 10 Mbit/s of bandwidth, a payment took 19 to 53 ms longer per hop, mostly from moving the 21.8 kB ciphertext list, not from the cryptography.

The cost is gossip. Each channel's gossip grows from about 0.8 kB to 8.1 kB to download, and from 1.1 kB to 9.7 kB to store. The paper puts today's network at 33,000 public channels. A node joining from scratch would download about 270 MB instead of 26 MB and keep a 320 MB graph instead of 36 MB. With FN-DSA-512, the smaller Falcon-based signature NIST has selected but not yet published as a standard, the growth drops to about four times, or 115 MB to download. Osuntokun's June estimate for converting every gossip signature to ML-DSA-44 was 29 times; PQLN stays near 10 because the largest gossip message, channel_announcement, stays classical.

Only nodes that sync the full graph pay this. The paper notes that rust-lightning's mobile wallets fetch a compressed, signature-free snapshot of the graph from a server instead, through rapid gossip sync, and that server could add the post-quantum keys. Those wallets would trust the server for the keys, just as they already trust it for the graph.

Does it work with ordinary nodes?

The authors ran 12 scenarios mixing PQLN and unmodified nodes, from opening a channel to BOLT 12 refunds and asynchronous payments. When both ends and every hop spoke post-quantum, payments used the full protection. When an ordinary node sat on the route, the payment fell back to classical cryptography and still went through. With the require-post-quantum setting turned on, a node refused the downgrade and the payment failed before any HTLC was sent, which is the safe failure.

That fallback matters. It means a node can start using PQLN without waiting for the rest of the network, and it means protection is only as strong as the least upgraded hop unless the node insists.

What is still open?

• Trust on first use. Pinning only protects two nodes that met before a quantum computer arrived. A node that first meets a peer afterwards could pin an attacker's key. The paper suggests having each channel's funding key commit to its owner's post-quantum keys, the way Taproot commits to a script tree, but leaves that to future work.
• No key rotation yet. A pinned key cannot be replaced cleanly, which matters after a compromise or a move to FN-DSA.
• Some signatures stay classical. A first payment to an unannounced BOLT 11 payee, and the payer's side of a BOLT 12 request, have no trusted post-quantum key to check against.
• Not yet in the BOLTs. The new message fields, invoice tags and feature bits still need assignment through the BOLT process, and testing so far covers only rust-lightning, not Core Lightning, LND or Eclair.
• Relay limits. Unmodified rust-lightning refuses to relay gossip with more than 1,024 bytes of unknown data, so PQLN gossip only spreads between PQLN nodes unless that limit is raised. Kurt has asked the rust-lightning maintainers about it.

What should a Lightning user do now?

• Nothing urgent. No quantum computer can break secp256k1 today, and that has not changed. PQLN is research code, not a release.
• Know which part of your Lightning balance is which. Channel funds sit on the chain behind secp256k1 keys. If the channel is public, those keys are published in gossip for as long as it stays open.
• Treat long-idle public channels like any open box. Closing a channel you no longer use moves the coins to an on-chain output your wallet controls, and a fresh, never-spent address keeps its key hidden. How to move coins to a still-closed address covers the on-chain side.
• Watch for two separate milestones. PQLN-style upgrades protect privacy and message authenticity, and could ship node by node. Protecting channel funds needs a new Bitcoin output type and post-quantum signatures on the base layer first.