Bitcoin may go quantum-safe while Lightning privacy stays exposed

A Sept. 12 research preprint proposes PQLN, a hybrid post-quantum extension built as a rust-lightning research prototype, to protect five off-chain Lightning Network functions that would remain exposed even if Bitcoin adopts post-quantum on-chain protections. The authors' 12-scenario matrix found post-quantum and vanilla binaries from the same rust-lightning base could coexist, but default ML-DSA-44 and ML-KEM-768 settings increased gossip downloads 10.2 times and stored graph data 8.8 times versus vanilla Lightning, while a fixed 21.8-kilobyte post-quantum ciphertext list added 19 to 53 milliseconds per hop on an emulated 10 Mbit/s link. The preprint assumes a future cryptographically relevant quantum adversary, does not report a present-day compromise, and leaves on-chain keys protecting funding, commitment and HTLC outputs unsecured.

Even if Bitcoin eventually adopts post-quantum protections for on-chain outputs, five parts of the Lightning Network’s off-chain payment system would still need separate upgrades, according to a Sept. 12 research preprint. The paper proposes PQLN, a hybrid post-quantum extension implemented as a rust-lightning research prototype. It targets gossip, which distributes node and channel information; encrypted peer connections; signed invoices and reusable payment offers; and onion packets that conceal payment-routing details. Lightning currently uses secp256k1-based ECDSA, Schnorr signatures or ECDH across those functions. PQLN keeps the classical mechanisms while adding ML-DSA signatures to gossip, invoices and offers. It adds hybrid ML-KEM key exchange to transport, payment onions and BOLT 12 privacy paths. The authors built a feature-gated rust-lightning fork and a modified ldk-sample node. Their 12-scenario matrix found that post-quantum and vanilla binaries built from the same rust-lightning base could coexist. Depending on the route and settings, mixed setups used classical protection or failed closed. That compatibility does not establish network-wide readiness. The repositories describe the software as a research artifact, and the study deferred tests against other Lightning implementations. Communication, rather than raw cryptographic computation, dominated the authors’ results. During static synchronization of a full network graph, the default ML-DSA-44 and ML-KEM-768 design increased gossip downloads 10.2 times and stored graph data 8.8 times compared with vanilla Lightning. A smaller Falcon-derived FN-DSA configuration reduced the download multiple to 4.2 times, but NIST still lists that scheme as under development rather than a final standard. Private payment routing carried another bandwidth penalty. A fixed 21.8-kilobyte post-quantum ciphertext list added 19 to 53 milliseconds per hop on an emulated 10 Mbit/s link and 160 to 187 milliseconds per hop at 1 Mbit/s. By contrast, ML-DSA-44 signing averaged 327 microseconds on the authors’ 16-core AMD Ryzen Threadripper PRO 3955WX workstation with 64 GB of RAM. That author-run, hardware-specific primitive measurement should not be read as end-to-end payment latency. PQLN also leaves Bitcoin-rooted risks untouched. It does not secure the on-chain keys protecting funding, commitment and HTLC outputs or penalty transactions, so safeguarding channel funds still requires Bitcoin-layer post-quantum changes. The preprint assumes a future cryptographically relevant quantum adversary; it does not report a present-day quantum compromise of Bitcoin or Lightning. Its prototype suggests Lightning’s off-chain defenses can be tested independently of a Bitcoin upgrade, but not that the network is ready to migrate. In these experiments, the hard operational question was how much extra gossip, storage and payment traffic node operators could absorb.