Ahmet Kirk proposes post quantum Lightning upgrade
- Developer Ahmet Kirk proposed a post-quantum Lightning upgrade to protect off-chain payments from future decryption.
- The architecture maintains existing onion packet sizes but increases node gossip bandwidth up to tenfold.
- Core Lightning patched critical vulnerabilities that allowed peers to steal funds during forced channel closures.
Adversaries are logging encrypted Lightning Network traffic today to decrypt it when quantum computers arrive.
To counter that threat, developer Ahmet Kirk and co-author Abdullah published the Post-Quantum Lightning Network architecture. Built with 11,000 lines of Rust code and 100 tests, the prototype applies post-quantum primitives to gossip, transport, invoices, and onion routing without forcing a base-layer Bitcoin hard fork.
Preserving backward compatibility required novel engineering. Rather than cramming 1,088-byte MLKEM ciphertexts into fixed 1,300-byte onion packets, Kirk's design routes hybrid secrets alongside payment messages in 20-slot updates. The trade-off is bandwidth: nodes running NIST-standardized MLDSA-44 signatures consume ten times more gossip data than classical nodes, while unstandardized Falcon signatures reduce that overhead to fourfold.
While post-quantum upgrades address future risks, existing off-chain clients face immediate operational flaws. Core Lightning developers released emergency updates after discovering that peers could trick nodes into ignoring revoked commitments by issuing decoy shutdown requests during forced channel closures.
Additional fixes targeted peer-proposed fee rates during channel splices. To prevent database overflows that trapped restarting nodes in endless crash loops, developers instituted a strict fee ceiling of 4,000 satoshis per vbyte. Lightning Development Kit and LND maintainers published parallel patches adjusting fee bumping logic and ping rate limits.
At the base layer, Bitcoin Core contributors are preparing version 32.0 for release. On Bitcoin Optech, contributor Jan B highlighted the project's community testing campaign, which focuses on validating downstream setups like hardware wallets and block explorers ahead of a major rewrite of the node's HTTP server.
"Automated software tests cannot replicate a node running in someone's closet."
- Jan B, Bitcoin Optech
The rewrite removes legacy libraries in favor of strict RFC compliance, leaving downstream maintainers racing to update client software before node operators deploy the binary.
Source Intelligence
- Deep dive into what was said in the episodes
Bitcoin Optech: Newsletter #424 Recap • Oct 1
- Ahmet Kirk argues that even if Bitcoin receives an on-chain post-quantum upgrade, Lightning's off-chain components like gossip and onion routing remain vulnerable. Decoupled upgrades are necessary because attackers could record current traffic to decrypt it later.
- Ahmet Kirk's proposal distributes post-quantum node identities via gossip, upgrading two of three gossip messages while leaving channel announcements classical. The transport layer relies on BIP 8 to integrate post-quantum primitives next to classical ones.
- Ahmet Kirk states that Bolt 11 post-quantum signatures fit within QR code limits using MLDSA-44 signatures. Because Rust Lightning has a 639-byte message limit, PQLN splits the signature across four tag fields.
- To keep onion packets under the 1,300-byte limit, Ahmet Kirk's design avoids sending 1,088-byte MLKEM ciphertexts inside the onion. Instead, per-hop secrets are made hybrid and travel alongside the onion in a fixed-size list of 20 slots.
- Ahmet Kirk reports that PQLN adds 11,000 lines of Rust code and 100 tests. MLDSS signing adds a negligible 0.33 milliseconds of overhead, but gossip bandwidth increases tenfold with MLDSA-44 or fourfold with Falcon.
- Core Lightning 26.06.8 acts as a security release that temporarily withholds certain tests to prevent attackers from finding vulnerabilities. PR 9507 caps peer-proposed fee rates at 4,000 sats per vB to prevent overflow bugs that crash restarting nodes.
- Core Lightning fixed vulnerabilities where peers could trick nodes into ignoring force-closed revoked commitments by sending a decoy shutdown message. Other fixes address nodes losing splice signature memory across restarts and limit peers to three concurrent negotiations.
- Core Lightning PRs 9510 and 9511 mitigate crash risks by capping JSON nesting to 256 levels and rejecting oversized DNS hostnames. PR 9513 now validates that Bolt 12 fetched invoice amounts do not exceed requested or offered parameters.
- LDK 0.3 release candidate 2 introduces RBF fee bumping for stuck splices, defaults to negotiating anchor channels, and invalidates older Bolt 11 invoices. The LDK project has also migrated its repository off GitHub to a self-hosted mirror.
- LND restored Bolt 1 compliance by ensuring it replies to all valid ping messages. This fix preserves the inbound rate-limiting and bucket protections against ping-based denial of service attacks introduced in a previous release.
Also discussed on this episode: (5)
Protocol (4)
- Jan explains that Bitcoin Core 32.0 release candidate 2 is feature-complete ahead of its October 10th target. The associated testing guide covers 10 tests across four groups on Regtest, focusing on new RPCs and the HTTP server rewrite.
- Jan highlights key Core 32.0 features, including getopenrpcinfo for machine-readable RPC diffs, PSBT version 2 by default, and exportwatchonlywallet for phone tracking. The HTTP server is rewritten from scratch to remove libevent and enforce stricter RFC compliance.
- A Stack Exchange contributor explains that Taproot commits to every individual input amount rather than just the sum. Committing only to the total allows a malicious machine to shuffle amounts between inputs to steal funds in a coinjoin.
- Bitcoin Knots nodes that split off during the failed BIP 110 activation in August do not need a full re-sync. Because the minority chain quickly stalled, pruned nodes still hold the last common block and can reorg automatically.
Lightning (1)
- LND updated its Atomic Multipath Payments (AMP) logic to prevent whole-invoice cancellations when a single path fails. Additionally, LND introduced validation logic ensuring returned Bolt 12 invoices are signed by the actual receiver.