A post-quantum Lightning proposal would cost nodes ten times the bandwidth
Serguey Asael Shinder2 min readA proposal for making the Lightning Network's off-chain protocols resistant to quantum computers, called PQLN, was posted to the Delving Bitcoin forum by Ahmet Kurt and summarised in Bitcoin Optech Newsletter #424 on 25 September. A working implementation based on rust-lightning is available for testing. Everything that touches the blockchain - funding and closing transactions - is deliberately left alone, because changing it would need a Bitcoin consensus change.
The design touches four layers. In gossip (BOLT 7), a node announces its ML-DSA and ML-KEM public keys together with an ML-DSA signature, and those keys are pinned so later announcements cannot swap them; channel_announcement is left unchanged because two of its four signatures come from on-chain funding keys and would stay forgeable. The Noise transport handshake (BOLT 8) becomes hybrid, with two ML-KEM encapsulations, one to the pinned static key and one to a fresh ephemeral key for forward secrecy. Invoices (BOLT 11) cannot hold a 2,420-byte ML-DSA-44 signature in one 639-byte tagged field, so it is split across several, with a fresh key committed per invoice. Onion routing (BOLT 4) keeps its format; ML-KEM ciphertexts travel alongside in 20 slots of update_add_htlc, unused slots padded with dummies so the route length does not leak.
Kurt's own accounting is that computation is not the problem - ML-DSA signing takes about 0.33 ms - but bandwidth is: a PQLN node downloads roughly ten times and stores nine times the data of an ordinary node. On regtest, PQLN nodes fell back to the classical protocol when a classical node was on the route, or failed before sending any HTLC when a require-PQ flag was set.
What it means
The proposal is useful mainly because it maps where quantum resistance can be added to Lightning today and where it cannot. The off-chain layers can move independently; the channels themselves remain protected by the same signatures as the rest of Bitcoin until the base layer changes. A post-quantum Lightning node would therefore protect its gossip, invoices and payment privacy against a future attacker, not the funds locked in channels.
The open problems the author lists are the ones to watch. Key pinning only protects peers that met before a capable quantum computer existed. A 1,024-byte relay limit in rust-lightning stops ordinary nodes from forwarding PQ gossip. Feature bits and TLV types are not yet assigned. None of this is close to deployment, and nothing here requires action from node operators now; it is a design to review rather than a feature to schedule.