arXiv CSopen access

PQLN: Post-Quantum Security for the Bitcoin Lightning Network's Off-Chain Surfaces

1

PQLN: Post-Quantum Security for the Bitcoin Lightning Network’s Off-Chain Surfaces

arXiv:2609.13781v1 [cs.CR] 12 Sep 2026

Ahmet Kurt , Abdul-Salem Beibitkhan , Yacoub Hanna , and Abdullah Aydeger

Abstract—A cryptographically relevant quantum computer will break the elliptic-curve cryptography behind Bitcoin and its Lightning Network, the most widely used payment channel network. Even a post-quantum consensus upgrade of Bitcoin would not cover Lightning’s off-chain surfaces, so its gossip, peer transport, invoices, payment onions, and offers need separate protection. An adversary can already record Lightning’s encrypted traffic today and decrypt it once such a computer exists. Lightning can therefore move to post-quantum cryptography now, without waiting for Bitcoin, and stop such harvest-nowdecrypt-later attacks along with node impersonation, invoice forgery, and payment deanonymization. In this paper, we propose PQLN, a hybrid post-quantum extension of Lightning that protects all of these surfaces with the lattice-based standards ML-DSA and ML-KEM. PQLN distributes post-quantum node identities through Lightning’s gossip, hybridizes the transport handshake, adds post-quantum signatures to invoices, commits post-quantum keys in offers, and makes payment onions hybrid. Since post-quantum material is much larger than its elliptic-curve counterpart, we introduce techniques that fit it into Lightning’s existing message formats and size limits. We analyze the security of PQLN against a quantum adversary and implement it in rustlightning, a major Lightning implementation. Our evaluation with real Lightning nodes shows that PQLN nodes interoperate with unmodified nodes. The added cryptographic operations take at most 0.33 milliseconds, and the main cost is communication, since gossip data grows about tenfold with ML-DSA and about fourfold with the smaller Falcon. To our knowledge, PQLN is the first post-quantum design, implementation, and evaluation for Lightning. Index Terms—Lightning Network, Bitcoin, post-quantum cryptography, ML-DSA, ML-KEM, payment channel networks.

I. I NTRODUCTION UBLIC-KEY cryptography in use today rests on the hardness of integer factorization and discrete logarithms, and Shor’s algorithm solves both problems in polynomial time on a sufficiently large quantum computer [1]. Recent advances have narrowed the gap between theory and practice, since Google’s Willow processor demonstrated a logical qubit whose error rate decreases as more physical qubits are added [2], while estimates of the resources required to break 256-bit elliptic-curve keys continue to fall [3], [4]. Moreover, adversaries can record encrypted traffic today and decrypt it

P

(Corresponding author: Ahmet Kurt.) Ahmet Kurt is with East Texas A&M University, RELLIS Campus, Bryan, TX 77807 USA (e-mail: [email protected]). Abdul-Salem Beibitkhan is with North American University, Stafford, TX 77477 USA (e-mail: [email protected]). Yacoub Hanna is with Florida Gulf Coast University, Fort Myers, FL 33965 USA (e-mail: [email protected]). Abdullah Aydeger is with the Florida Institute of Technology, Melbourne, FL 32901 USA (e-mail: [email protected]).

once a cryptographically relevant quantum computer exists, a strategy known as harvest-now-decrypt-later [5], [6]. In response, the National Institute of Standards and Technology (NIST) published its first post-quantum (PQ) cryptography standards in August 2024, including the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) and the ModuleLattice-Based Digital Signature Algorithm (ML-DSA) [7], [8]. NIST also plans to disallow elliptic-curve signatures and key exchange after 2035 [6]. These concerns are especially pressing for cryptocurrencies since they rely on elliptic-curve cryptography to protect highvalue digital assets. Bitcoin [9] is the most consequential case because it accounts for more than half of the market capitalization of all cryptocurrencies.1 Bitcoin authorizes transactions with secp256k1 signatures, and a quantum adversary that observes a public key could use Shor’s algorithm to recover the corresponding private key [10]. Indeed, around 6.9 million BTC, more than a third of the circulating supply, reside in outputs with exposed public keys [3]. However, addressing this vulnerability at the Bitcoin base layer is difficult because replacing the underlying cryptography requires a consensus upgrade, and the current PQ proposals remain at an early stage [11]. The Lightning Network (LN) [12] is a second-layer protocol that turns Bitcoin into an instant payment system by moving payments into off-chain channels. At the time of writing, LN is the most widely used payment channel network with around 16,000 nodes and 33,000 public channels holding roughly 3750 BTC.2 LN also entered mainstream use when Coinbase enabled Lightning transfers in 2024.3 However, LN’s own protocol stack is as quantum-exposed as the base layer. Nodes authenticate gossip with the Elliptic Curve Digital Signature Algorithm (ECDSA), derive the keys of every peer connection from Elliptic Curve Diffie-Hellman (ECDH), sign payment requests with ECDSA and Schnorr signatures, and build payment onions from one ECDH secret per hop. All of these operations rest on the hardness of the elliptic-curve discrete logarithm problem, which Shor’s algorithm solves. A quantum adversary can therefore impersonate nodes, decrypt recorded transport sessions, forge payment requests, and deanonymize payments. Despite this exposure, LN has no PQ defense to date, and the only prior examination is a forum analysis that stops short of a design [13]. 1 https://coinmarketcap.com/charts/bitcoin-dominance/ 2 https://mempool.space/lightning 3 https://www.coinbase.com/blog/coinbase-integrates-bitcoins-lightning-net work-in-partnership-with

2

However, only part of Lightning’s exposure is rooted in Bitcoin. The keys and signatures behind channel funds live inside Bitcoin transactions, so they cannot change without a fork. Everything else lives purely off-chain in messages between Lightning nodes, so these off-chain surfaces can adopt PQ cryptography through a software update alone. They also stay exposed after Bitcoin adopts PQ outputs, because a baselayer upgrade does not cover them. In other words, Lightning has to protect these surfaces itself, and it can do so before Bitcoin completes its own transition. In this paper, we propose PQLN, a PQ extension of Lightning that protects its off-chain surfaces. PQLN follows a hybrid conservative-extension approach, meaning that every classical mechanism stays in place with ML-DSA and MLKEM added alongside it, so Lightning’s security remains intact. However, hybridizing the primitives is only the starting point, because their deployment faces four obstacles. First, Lightning has no certificate infrastructure to distribute PQ keys. PQLN therefore turns LN’s gossip into a key distribution channel, where every node announces its PQ keys and others pin them on first sight. For payees absent from gossip, a reusable payment offer additionally commits a fresh signing key. Second, a quantum adversary can forge any negotiation message, so we run the hybrid transport handshake on a dedicated port without in-band negotiation and check for downgrades against pinned or offer-committed keys. Third, PQ keys, signatures, and ciphertexts are much larger than their classical counterparts and do not fit into Lightning’s messages. For example, a 2420-byte ML-DSA-44 signature has to fit into invoice fields of at most 639 bytes each. Similarly, one 1088-byte ML-KEM-768 ciphertext would nearly fill the 1300byte onion payload, and a payment needs one per hop. PQLN therefore splits oversized signatures into chunks and carries the ciphertexts in a fixed-size list beside the unchanged onion. Finally, the network cannot upgrade at once, so PQLN nodes have to coexist with unmodified nodes. The Lightning protocol lets unmodified nodes skip optional fields, so PQLN carries these additions in such fields. PQLN nodes can thus join today’s network without a coordinated upgrade. Our evaluation with real Lightning nodes shows that 1) the added cryptographic operations take at most 0.33 ms each and a PQ payment adds less than 60 ms per hop on a typical Internet link; 2) the main cost is communication, since a PQLN node downloads about 10 times as much gossip data as an unmodified node, or about 4 times as much with FN-DSA, the smaller Falcon-based signature scheme under standardization at NIST [14]; and 3) upgraded and unmodified nodes interoperate across the main Lightning operations, from channel opening to invoice, offer, and multi-hop payments. Our contributions in this work are as follows: We propose PQLN, a PQ design for Lightning’s offchain surfaces that requires no change to Bitcoin and interoperates with unmodified nodes. • We turn LN’s gossip into quantum-safe key distribution with trust-on-first-use pinning, and resist downgrade attacks by relying on pinned or offer-committed keys rather than forgeable negotiation messages. •

We introduce signature chunking for the 639-byte invoice fields and a fixed-size ciphertext list beside the 1300byte payment onion, which fit the large PQ material into message formats with hard size limits. • We analyze the security of PQLN against a quantum adversary and reduce each guarantee to the standard security notions of ML-DSA and ML-KEM. • We implement PQLN by modifying the source code of rust-lightning [15] and evaluate its computational and communication overhead, payment latency, and interoperability with real Lightning nodes, at every NIST parameter set and with FN-DSA in place of ML-DSA. Our code is publicly available at our GitHub repository.4 The rest of the paper is organized as follows. Section II reviews the related work. Section III provides background on LN and the PQ standards. Section IV presents the design of PQLN and its threat model. Section V analyzes its security. Section VI presents our evaluation. Section VII discusses the limitations and Section VIII concludes the paper. •

II. R ELATED W ORK We review the efforts closest to PQLN and show why none of them closes this gap. Table I summarizes the comparison, where the LN column denotes protecting Lightning’s offchain surfaces and the last column denotes running alongside unmodified nodes. Research on quantum attacks against Bitcoin has concentrated on the base layer [3], [4], and so have the proposed mitigations. Stewart et al. [16] introduced a commit-delay-reveal protocol that migrates funds to a quantum-resistant scheme even after ECDSA is compromised. Bitcoin Improvement Proposal (BIP) 360 defines a Taprootlike output type that removes the quantum-vulnerable key-path spend [11], and Kudinov and Nick [17] tailored hash-based signatures to Bitcoin with much smaller sizes than the standardized Stateless Hash-Based Digital Signature Algorithm (SLH-DSA). Levy [18] proposed quantum-safe transactions that need no consensus change, though the scheme does not yet cover Lightning channels. All of these efforts stop at the base layer, and none attempt a Lightning design. TABLE I C OMPARISON OF PQLN WITH THE C LOSEST R ELATED W ORK (✓ Y ES , ∼ PARTIAL , × N O , N / A N OT A PPLICABLE ) Related work LN Design Impl. Interop. Bitcoin base-layer migration [11], [16]–[18] × ✓ ∼ n/a PQ transport [19]–[22] × ✓ ✓ n/a PQ onion routing [23], [24] × ✓ ∼ n/a PQ adaptor signatures [25], [26] × ✓ ∼ × Lightning PQ analysis [13] ∼ × × n/a PQLN (this work) ✓ ✓ ✓ ✓

Deployed protocols are further along in the same transition. TLS 1.3 negotiates hybrid groups that combine ML-KEM with an elliptic-curve exchange [19], and KEMs can even replace the handshake signatures [20]. OpenSSH has defaulted to a hybrid PQ key exchange since version 9.05 and Signal deployed a hybrid PQ handshake [21]. Angel et al. [22] relate 4 https://github.com/ahmet-kurt/pq-rust-lightning 5 https://www.openssh.org/pq.html

3

most directly to our transport work, since they replaced the Diffie-Hellman (DH) operations of Noise with KEMs. None of these works targets Lightning or any payment channel network. PQLN brings the same migration practice to Basis of Lightning Technology (BOLT) 8 by hybridizing Noise_XK while keeping the classical handshake byte-identical. For onion routing, Ghosh and Kate [23] proposed HybridOR, a hybrid circuit-extension key exchange for Tor. Rial et al. [24] later rebuilt the Sphinx packet format around KEMs with Outfox, which carries one KEM ciphertext per hop and therefore suits only fixed-length routes. Neither work targets Lightning’s payment onion, whose packet carries a fixed 1300byte payload over a variable number of hops. PQLN protects this surface by keeping the packet untouched and carrying the ML-KEM ciphertexts beside it (Section IV-F). PQ adaptor signatures target payment channels directly. Esgin et al. [25] built payment channel networks from the first PQ adaptor signature, and Tairi et al. [26] followed with an isogeny-based construction for privacy-preserving offchain payments. Both would protect the funds inside channels once Bitcoin can verify their signatures, which it cannot do today, whereas PQLN protects the surfaces that no base-layer upgrade touches. Kiayias and Litos [27] formally proved the security of the Lightning protocol in the universal composition setting, and Kurt et al. [28] extended Lightning to resource-constrained IoT devices through threshold cryptography, though both assume a classical adversary. The only Lightning-specific examination of the quantum threat is a forum post by Osuntokun [13], which weighs PQ candidates for each layer and stops short of a design or an implementation. To the best of our knowledge, PQLN is thus the first design, implementation, and evaluation of PQ protection for Lightning’s off-chain surfaces. III. P RELIMINARIES This section provides background on LN and the PQ standards. We explain the LN mechanisms on the example of Fig. 1, in which Alice pays Carol through Bob, and note the elliptic-curve operation behind each mechanism. A. Lightning Network LN is a payment channel network on top of Bitcoin [12]. Every LN node is identified by a secp256k1 public key called the node id, with which it authenticates its transport sessions and signs its gossip messages and payment requests. The BOLT specifications define the protocol in numbered documents [29]. Payment Channels: Alice opens a channel to Bob with a funding transaction that locks her coins into an output under the control of both parties, and the channel balances live in commitment transactions that the parties update and sign at every payment. Broadcasting the latest commitment transaction closes the channel, while broadcasting an outdated one lets the counterparty claim the entire balance through a penalty transaction. All three are ordinary Bitcoin transactions, so the safety of the funds inside a channel rests on Bitcoin’s own cryptography.

Lightning Network (off-chain) 1

nodes learn the topology through gossip (BOLT 7)

2

invoice (BOLT 11) or

offer (BOLT 12)

channel

Alice

channel

Bob

encrypted transport (BOLT 8)

3

onion-routed payment (BOLT 4) locks an HTLC in each channel

4

the preimage settles the HTLCs

Carol

Bitcoin blockchain (on-chain) funding tx (opens)

commitment tx (closes)

Fig. 1. Overview of an LN payment.

Gossip: Nodes learn the network topology through the gossip messages of BOLT 7. Every node broadcasts a node_announcement that advertises its identity, features, and network addresses. A public channel enters the graph through a channel_announcement signed by both node keys and both funding keys, and both endpoints broadcast channel_update messages that advertise their forwarding fees and policies. All of these messages are signed with the announcing nodes’ ECDSA keys, and nodes assemble them into the network graph to compute payment routes. Transport: Two connected nodes exchange all protocol messages inside an encrypted and authenticated session defined in BOLT 8. The session keys are derived with the Noise_XK handshake [30], which runs three ECDH operations on secp256k1. The handshake authenticates the responder against its static public key, so the initiator must know this key in advance. Payments: A payment starts when Carol hands Alice a BOLT 11 invoice, typically as a QR code. The invoice carries the amount and a payment hash chosen by Carol, and she signs it with a recoverable ECDSA signature under her node key, from which Alice recovers Carol’s node id. BOLT 12 offers extend this flow with a small long-lived payment code that is published once and paid many times. A payer that scans an offer requests a fresh invoice from the payee, who signs it with a Schnorr signature. A payment can traverse multiple channels through intermediaries such as Bob, so Alice needs no channel to Carol. Every channel on the route locks the payment amount in a Hash Time Locked Contract (HTLC) that pays out against the preimage of the payment hash and refunds the sender after a timeout. Carol therefore claims the payment by revealing the preimage, which settles every HTLC back along the route. Payment Onion: A payment’s routing information travels in a Sphinx onion packet [31] with a fixed payload of 1300 bytes, as defined in BOLT 4. The sender derives one ECDH secret per hop and encrypts the routing information in layers, so each

4

TABLE II L IGHTNING P ROTOCOL S URFACES V ULNERABLE TO S HOR ’ S A LGORITHM AND T HEIR T REATMENT IN PQLN BOLT 1, 10 2 3 4 5 7 8 9 11 12

Scope of the specification Base protocol and DNS bootstrap Peer protocol for channel management Bitcoin transaction and script formats Onion routing protocol On-chain transaction handling P2P node and channel discovery Encrypted and authenticated transport Assigned feature flags Invoice protocol for payments Flexible protocol for payments (offers)

Shor-vulnerable surface None ECDSA over on-chain transactions secp256k1 keys inside Bitcoin Script Per-hop ECDH ECDSA over on-chain transactions Node-key ECDSA on gossip messages ECDH in the Noise handshake None Node-key recoverable ECDSA Schnorr signatures and per-hop ECDH

hop learns only its predecessor and its successor. A payee that wants to hide its identity can additionally use blinded paths, which replace the final hops of the route with encrypted routing data that it prepares with the same per-hop ECDH. The same construction also carries the onion messages that BOLT 12 uses to request invoices. Extensibility: LN messages are extended with appended Type-Length-Value (TLV) records. BOLT 1 makes a record with an odd type optional, so an implementation that does not recognize it skips the record, whereas an unknown even type fails the message. The specifications call this rule it’s ok to be odd. BOLT 11 decoders likewise skip unknown tagged fields, and nodes advertise capabilities through the feature bits of BOLT 9. These mechanisms let upgraded and unmodified nodes coexist, and PQLN uses them to interoperate with today’s network. B. Post-Quantum Standards PQLN uses two of the PQ standards that NIST published in August 2024, namely ML-DSA for signatures and ML-KEM for key exchange. Both rest on lattice problems that no known quantum algorithm solves efficiently. ML-DSA: ML-DSA is standardized in FIPS 204 and originates from CRYSTALS-Dilithium [8]. It offers the same interface as ECDSA and Schnorr, so a protocol can attach an ML-DSA signature wherever it already produces a classical one. ML-DSA also binds an application-chosen context string into every signature, so a signature created for one purpose cannot be reused for another. ML-KEM: ML-KEM is standardized in FIPS 203, originates from CRYSTALS-Kyber, and takes the place of DH key agreement [7]. Key generation produces an encapsulation key and a decapsulation key. Anyone holding the encapsulation key can encapsulate, which yields a fresh shared secret and a ciphertext, and decapsulating the ciphertext with the decapsulation key recovers the same secret. A protocol must therefore know a party’s encapsulation key in advance and deliver the ciphertext to that party. Decapsulating a mismatched or tampered ciphertext does not fail but returns an unrelated secret, a behavior called implicit rejection. FN-DSA: NIST also selected Falcon [14] for standardization in FIPS 206 and renamed it the FFT over NTRU-LatticeBased Digital Signature Algorithm (FN-DSA), but had not yet published the standard at the time of writing. Its keys and signatures are much smaller than those of ML-DSA, but its key generation is far slower, and Section VI measures it as an alternative to ML-DSA.

Treatment in PQLN Not applicable Out of scope (rooted on-chain) Out of scope (requires a Bitcoin change) Protected, hybrid ML-KEM (Sec. IV-F) Out of scope (rooted on-chain) Protected, ML-DSA (Sec. IV-B) Protected, hybrid ML-KEM (Sec. IV-C) Two experimental feature bits registered Protected, ML-DSA (Sec. IV-D) Protected, ML-DSA and hybrid ML-KEM (Sec. IV-E)

IV. PQLN D ESIGN This section presents the design of PQLN. We first give an overview and the threat model, and then treat each surface in turn. Two hard constraints shape the design, one imposed by Bitcoin and one by the network itself. First, no Lightning upgrade can change Bitcoin’s consensus rules, so the secp256k1 keys inside funding, commitment and penalty transactions stay as they are. Second, the network cannot be upgraded at once, so every mechanism has to interoperate with unmodified nodes, which we call vanilla nodes. PQLN therefore targets the protocol surfaces that live purely off-chain and adds its protection where the extensibility rules of Section III-A let vanilla nodes skip it as unknown data. Table II maps every BOLT [29] to its Shor-vulnerable surface and to its treatment in PQLN. The surfaces of BOLTs 2, 3 and 5 are rooted in Bitcoin transactions and are therefore out of scope. The remaining five BOLTs carry cryptography that lives purely off-chain, and PQLN protects all five of them. PQLN follows a hybrid conservative-extension approach. It keeps all of the existing secp256k1 cryptography in place and adds a PQ primitive to every protected surface, as TLS and Signal do [19], [21]. Against a classical adversary, PQLN is therefore at least as secure as vanilla Lightning, and a quantum adversary additionally has to break the PQ primitive. We use the two NIST PQ standards of Section III-B. Signatures use ML-DSA-44 with public keys of 1312 bytes and signatures of 2420 bytes [8]. We chose the smallest standardized parameter set because signature and key material dominates our wire overhead. FN-DSA would shrink this material further, but its standard is not final, so we keep MLDSA-44 as the default and measure FN-DSA as an alternative in Section VI. Key exchange uses ML-KEM-768, the set that TLS and OpenSSH adopted, with encapsulation keys of 1184 bytes, ciphertexts of 1088 bytes and 32-byte shared secrets [7]. Every node derives its ML-DSA signing key and its static MLKEM key from its existing seed at two dedicated hardened BIP 32 indices [32], so the wallet backup that restores its classical identity also restores its PQ identity. Hardened derivation is one-way, so a node key recovered with Shor’s algorithm reveals nothing about the PQ keys derived from the same seed. The gossip layer distributes these keys and serves as the trust anchor of PQLN. Every node publishes its ML-DSA and ML-KEM public keys inside its signed node_announcement, and every PQLN node pins these keys on first sight. All other surfaces then verify against the pinned keys under this truston-first-use model. The only exception is BOLT 12, where an offer additionally commits a per-offer signing key so that

5

invoice verification works even for payees that never appeared in gossip. PQLN also registers two experimental feature bits so that peers can discover support. However, a quantum adversary can flip these bits, so no security decision depends on them. The signature surfaces of gossip, invoices and offers are always on, so a PQLN node attaches its PQ signatures wherever it signs. A vanilla peer ignores them, whereas a verifier with a trusted key gains the protection. The remaining surfaces, namely the transport, the payment onion and the blinded paths, rely on key exchange and need both endpoints to take part. They are therefore explicit opt-ins through a dedicated PQ port and the three configuration flags of Sections IV-E and IV-F. A. Threat Model We assume an adversary that possesses a cryptographically relevant quantum computer and runs Shor’s algorithm at scale [1]. It recovers the secret key behind any secp256k1 public key that it observes [10]. It can therefore forge the ECDSA and Schnorr signatures of any node whose key appeared in gossip, in an invoice or on the wire, and it can compute the shared secret of any ECDH exchange from the two public keys alone. Symmetric primitives and hash functions only face Grover’s quadratic speedup, and the parameter sizes in use absorb it with an ample margin [33]. We therefore treat ChaCha20-Poly1305, SHA-256 and HMAC as secure. The adversary attacks on two timelines. In the retroactive timeline, it records classical traffic today and breaks it once a quantum computer exists. This harvest-now-decrypt-later strategy already endangers Lightning’s confidentiality surfaces [5], [6]. In the live timeline, it attacks in real time by forging signatures, substituting keys and inserting itself into new sessions. We also grant the adversary full control of the network, so it observes, delays, modifies and injects messages between any pair of nodes. Moreover, it participates in the network itself by running well-connected nodes, opening channels, relaying gossip and forwarding payments. It can also act as the counterparty, the routing hop or the payee of a victim. Based on this adversary, we consider the following attacks against Lightning: • Threat 1. Node Impersonation: The adversary forges a victim node’s gossip signatures to announce substituted keys or attacker-chosen parameters on the victim’s behalf. • Threat 2. Transport Decryption: The adversary breaks the ECDH operations of the BOLT 8 handshake to decrypt recorded sessions or to impersonate a responder in new sessions. • Threat 3. Invoice Forgery: The adversary forges the payee signature on a BOLT 11 or BOLT 12 invoice to substitute the payment hash, the amount or the payment paths. • Threat 4. Payment Deanonymization: The adversary recovers the per-hop ECDH secrets of the payment onion, unwraps its layers and links payer, route and payee. The same capability strips the privacy of blinded paths and onion messages. • Threat 5. Downgrade Attacks: The adversary strips or tampers with the PQ additions of a message so that the receiver processes it as a vanilla message, and then breaks the exchange like any other vanilla exchange.

node_announcement (adds 4928 B) covered by the ML-DSA signature ECDSA signature

vanilla fields

27: ML-DSA 29: ML-KEM 31: ML-DSA public key, 1312 B public key, 1184 B signature, 2420 B

covered by the ECDSA signature, verifiable by vanilla nodes channel_update (adds 2424 B) ECDSA signature

vanilla fields

vanilla field

31: ML-DSA signature, 2420 B

PQ addition

(a) Node N (PQ)

Verifier V (PQ)

Attacker M (quantum)

1. node_announcement {records 27, 29, 31} verify ECDSA and ML-DSA, then pin N's keys on first sight

2. channel_update {record 31} verify under N's pinned ML-DSA key

3. forged announcement {keys substituted in 27, 29} reject, keys differ from N's pin

4. forged announcement or update {records stripped} reject, pinned node lacks the records

(b)

Fig. 2. The PQLN gossip design. (a) The extended gossip messages. The MLDSA signature covers the published keys and the ECDSA signature covers the complete message. (b) The verifier pins a node’s keys on first sight and afterwards rejects substituted keys and stripped records.

Several threats are outside our model. Lightning-level mechanisms cannot prevent attacks on the Bitcoin layer, which await Bitcoin’s own PQ transition [10]. These include the theft of channel funds by breaking the secp256k1 keys of funding, commitment or HTLC outputs. Denial-of-service attacks are orthogonal to quantum resistance. We also assume that endpoints are not compromised. Finally, the trust-on-firstuse model assumes that a node pinned the keys of its peers before a cryptographically relevant quantum computer exists, since a first contact made afterwards can be intercepted by a live adversary. Section V states this assumption formally and Section VII discusses it. B. PQ Gossip (BOLT 7) We begin with gossip because it is the trust anchor of PQLN. The node_announcement and channel_update messages of Section III-A are signed only with the announcing node’s ECDSA key, so a quantum adversary could rewrite them freely (Threat 1). Every node already receives a node_announcement from every other node, so PQLN uses this message to publish a node’s ML-DSA and ML-KEM public keys to the whole network. Fig. 2(a) shows the modified messages. A PQLN node appends three odd TLV records to the tail of its node_announcement. Record 27 carries the node’s ML-DSA public key, record 29 carries its static ML-KEM encapsulation key and record 31 carries an ML-DSA signature over the serialized announcement, including the two key records. The ML-DSA signature is computed under a gossip-specific domain-separation context and appended last, and the node

6

then produces its classical ECDSA signature over the complete message. The classical signature thus commits to the PQ records, so a vanilla node verifies the announcement exactly as it does today and skips the unknown odd records under the it’s ok to be odd rule. A channel_update is extended the same way but carries only the signature record, since the verifier already knows the signer’s ML-DSA key from its node_announcement. Fig. 2(b) shows how a PQLN node processes incoming gossip. The verifier runs the PQ checks after the vanilla checks and updates its pins only after every check has passed. A rejected message therefore never alters a pin. Specifically, the verifier first checks the classical ECDSA signature as usual and then parses the PQ records. If the announcement carries a key without the signature, or the signature without the MLDSA key, the verifier rejects it as malformed. Otherwise, the verifier checks the ML-DSA signature against the embedded key. If the node is new, the verifier pins its ML-DSA and ML-KEM keys. If the node is already pinned, the verifier rejects the announcement in three cases, namely when a key differs from the pinned key, when a pinned key is missing, or when the signature is missing. A channel_update from a pinned node must likewise carry a valid ML-DSA signature under the pinned key, but it carries no keys and therefore never establishes a pin. Gossip relay needs one adjustment. Vanilla rust-lightning refuses to relay a gossip message when its unrecognized trailing data exceeds 1024 bytes, so a vanilla node accepts, verifies and stores a PQ announcement but does not forward it. PQLN raises this relay budget to 8192 bytes, so PQ gossip propagates across the PQ-aware part of the network, while a vanilla node on the way stops the propagation without rejecting the message. The budget caps the unrecognized data that a node relays per message at 1 kB for a vanilla node and 8 kB for a PQLN node, and relaying still requires valid signatures and a channel with an on-chain funding output, so the extra bytes stay tied to funded channels. Section VI-E confirms this behavior with real nodes. We deliberately leave channel_announcement, the third signed gossip message, classical. Two of its four signatures prove ownership of the on-chain funding output and cannot be protected off-chain, and protecting the two node-key signatures alone would leave a message that a quantum adversary can still half forge. A node’s identity keys and forwarding parameters stay fully protected through node_announcement and channel_update. C. PQ Transport (BOLT 8) Every Lightning message travels inside the BOLT 8 transport of Section III-A. Its Noise_XK handshake derives the session keys from three ECDH operations on secp256k1. The operation against the responder’s static key also authenticates the responder, and Shor’s algorithm breaks all three operations. A recorded session therefore becomes decryptable retroactively, and a live quantum adversary can impersonate any responder after observing its static key (Threat 2). PQLN hybridizes the handshake with two ML-KEM encapsulations, as shown in Fig. 3. The initiator must know the

Initiator I (PQ)

Responder R (PQ)

knows R's static ML-KEM key ekR (gossip pin or out of band) act one (e, es) 50 B

cts to ekR 1088 B

eke ephemeral 1184 B

total 2322 B decapsulate cts with the static key (proves R is the pinned responder), fold sss into the chaining key act two (e, ee) 50 B

cte to eke 1088 B

total 1138 B decapsulate cte with the ephemeral key, fold sse into the chaining key

act three (s, se), 66 B, unchanged transport keys derive from the chaining key, hybrid over es, sss, ee, sse, se

Fig. 3. The PQLN BOLT 8 handshake.

responder’s static ML-KEM key in advance, from the gossip pin of Section IV-B or out of band, just as Noise_XK already assumes for the classical static key. In act one, the initiator encapsulates to that pinned key and appends the ciphertext cts together with a freshly generated ephemeral ML-KEM public key eke . Only the true responder can decapsulate cts , which authenticates it against a quantum impersonator. The responder in turn encapsulates to eke and appends the resulting ciphertext cte to act two. This provides forward secrecy, since a later compromise of the static keys does not reveal the ephemeral secret. Act three stays unchanged. Each of the first two acts mixes its ECDH secret into the Noise chaining key, and the hybrid handshake folds the ML-KEM shared secret of the same act into the chaining key right afterwards. Both ciphertexts and eke are also absorbed into the transcript hash, so the session keys become hybrid over five shared secrets. PQLN deliberately has no in-band negotiation of PQ support, because a negotiation message is exactly what a quantum adversary could rewrite to force a downgrade (Threat 5). The hybrid handshake instead runs on a dedicated port, and the classical port stays byte-identical to vanilla. In our implementation, the operator supplies the PQ address of a peer, and a deployment would advertise it as an additional address in the node_announcement, which the pinned MLDSA signature already covers. Act three still authenticates the initiator classically, so a quantum adversary could connect under another node’s identity. This is of little value, since Lightning nodes accept inbound connections from anonymous peers by design and the other surfaces of PQLN authenticate every further action of a connected peer. D. PQ Invoices (BOLT 11) A BOLT 11 invoice commits to the payment hash, the amount and the destination of a payment. Its recoverable ECDSA signature is all that binds the request to the payee, and the payee’s node id is usually recovered from that signature rather than carried in the invoice. A quantum adversary that forges the signature can therefore substitute the payment hash and the destination of an intercepted invoice and collect the payment (Threat 3).

7

signed by the payee's ML-DSA key

signed by the payee's recoverable ECDSA key

record the committed key as the anchor, strip the PQ record from the request

carries PQ fields? yes

no

well formed and signature verifies?

trusted key? (pin or out of band)

2. invoice_request sent over a blinded onion message path

trusted key? (pin or out of band) no

yes

refused

yes paid, protected carried key must match

derive the per-offer ML-DSA key seed = HMAC(offer key, nonce) commit its public key in the offer metadata

1. offer {committed ML-DSA key, path cts} published once, scanned as a QR code or link

payer receives the invoice

yes

Payee (offer issuer)

ML-DSA public key ML-DSA signature ECDSA sig tag 25, 3 fields tag 22, 4 fields 65 B 1312 B 2420 B

timestamp, tagged fields

hrp

Payer (PQ)

refused (downgrade)

re-derive the per-offer key from the nonce, sign the invoice with ML-DSA and Schnorr

no paid classically

3. invoice {ML-DSA signature, path ct lists} returned over the reply path

no verify ML-DSA under the recorded key

paid, unanchored verified: pay

absent, invalid or foreign key: refuse

Fig. 4. The PQLN BOLT 11 invoices.

PQLN adds the payee’s ML-DSA signature and optionally the corresponding public key to the invoice. A BOLT 11 tagged field carries at most 639 bytes because of its 10-bit length encoding. PQLN therefore splits the two values into chunks and carries them as several tagged fields under two unassigned tag values, three fields for the public key and four for the signature (Fig. 4, top). A vanilla decoder skips unknown tagged fields, so the invoice still parses everywhere. The ML-DSA signature is computed over the human-readable part and the data part of the invoice, including the embedded public key fields, under an invoice-specific domain-separation context. The classical signature is produced afterward so that it commits to the PQ fields. Embedding the public key makes the invoice self-contained, while a payee that expects to be found in gossip can omit it and keep the invoice small enough for a QR code. Verification runs inside the pay path with no opt-in and applies the following policy (Fig. 4, bottom). Before dispatching any HTLC, the payer resolves a trusted key for the payee, from an out-of-band source or from the payee’s gossip pin. When a trusted key exists, the payer requires a valid MLDSA signature under that key and refuses the invoice as a downgrade if the signature is missing. It also refuses the invoice if an embedded public key differs from the trusted key. Without a trusted key, a vanilla invoice is paid as today, and an invoice that carries PQ fields is paid only if they are well formed and the signature verifies under any carried key. We call this last case unanchored, and it gives no protection because a signature under a self-asserted key proves nothing against an adversary who can mint both. A first contact with an unannounced payee therefore stays unprotected. E. PQ Offers (BOLT 12) With BOLT 12 offers, the payer sends an invoice_request to the payee over a blinded onion message path and receives a freshly signed invoice in return. The returned invoice is bound to the offer only by a Schnorr signature, so a quantum adversary between the two parties can forge it and substitute the payment hash, the amount or the payment paths (Threat 3). The gossip pin rarely helps here, since offer payees are commonly unannounced nodes reachable only through blinded

a static invoice served while the payee is offline verifies against the same key under a distinct domain

Fig. 5. The PQLN BOLT 12 offers.

paths. The privacy of the exchange in turn rests on the per-hop ECDH of those paths (Threat 4). PQLN closes this gap with a trust anchor already in the payer’s possession, namely the offer itself. When a PQLN node builds an offer, it derives a per-offer ML-DSA key and commits the public key inside the offer, as shown in Fig. 5. The signing seed is an HMAC of the node’s symmetric offer key and the offer’s nonce, so a quantum adversary cannot recover it from any published key, and distinct offers carry unlinkable keys. The committed key is carried in the offer’s metadata record, together with one ML-KEM ciphertext per PQ blinded path. Vanilla payers copy this record verbatim into the invoice_request and payees echo it back, so every classical implementation handles it consistently, whereas a PQLN payer strips it from its request. The payee re-derives the per-offer key from the offer’s nonce and signs the responding invoice under a BOLT 12 domain-separation context. The signature is placed in an odd record of the invoice’s experimental TLV range and written into the unsigned invoice, so the classical Schnorr signature covers it. A vanilla node ignores the unknown record but keeps it in place and still verifies the classical signature as usual. Verification again runs inside the pay path with no opt-in. A payer that scanned a PQ offer records the committed key, and the received invoice must verify under exactly that key before any HTLC is dispatched. The same anchor covers the static invoices that an often-offline payee pre-signs for asynchronous payments, and these verify under a distinct signing domain, so they cannot be replayed as regular invoices. The privacy surfaces of BOLT 12 use the hybrid key exchange of the payment onion. The recipient enables PQ blinded paths with the build_post_quantum_blinded_paths flag. The offer’s message paths, the reply path of the invoice_request and the blinded payment paths inside the invoice are then built with the hybrid route blinding of Section IV-F. Their ciphertexts reach the senders in the offer metadata, beside the reply path in the onion message and in a second experimental invoice record, respectively. Refund paths are

8

Sender

Hop 1

Hop 2

Recipient

encapsulate to each hop's pinned ML-KEM key eki, fold ssi into hop i's Sphinx secret, build the list

decapsulate the front entry, fold into the ECDH secret, peel the layer with hybrid keys, rotate the entry to the back

same, with ct2

decapsulate ct3, hybrid MAC verifies, error onion keyed by the same secrets

onion packet, 1300 B, size unchanged ct1

ct2

ct3

...

update_add_htlc

d

d

onion packet, 1300 B ct2

ct3

...

d

update_add_htlc

d

onion packet, 1300 B ct1

ct3

...

d

d

ct1

ct2

update_add_htlc

the list always holds 20 slots (21760 B), real ciphertexts first, then dummies d shaped like real ciphertexts, never decapsulated, so the list never reveals the route length or a hop's position (a blinded tail adds a second 10-slot list built by the recipient)

Fig. 6. The PQLN payment onion.

built the same way. Two BOLT 12 signatures remain classical, namely the payer’s signature on the invoice_request and the payee’s signature on a refund’s invoice, since the verifier has no trusted key for either signer.

F. PQ Payment Onion (BOLT 4) The Sphinx packet of Section III-A carries a fixed 1300byte payload, and the sender builds it from one ECDH secret per hop. Each hop derives the keys of its own layer from its ECDH secret, so a quantum adversary that recovers these secrets unwraps the route hop by hop, links payer to payee and reads every per-hop payload (Threat 4). An ML-KEM ciphertext of 1088 bytes would nearly fill the packet, and vanilla nodes cannot forward a packet of any other size. PQLN therefore keeps the onion payload at 1300 bytes and instead makes the per-hop keys hybrid. Fig. 6 shows the construction. For every hop, the sender encapsulates to the hop’s pinned ML-KEM key and folds the shared secret into the hop’s classical Sphinx secret, so the encryption and MAC keys of that layer become hybrid while the onion keeps its vanilla format. The ciphertexts travel beside the onion in a new odd field of update_add_htlc as a fixed-size list of 20 slots, the onion’s maximum hop count. Real entries come first in hop order and dummies fill the rest, so the list looks the same for every route length. The dummies are not random bytes but are compressed and encoded from uniformly random polynomial coefficients exactly as FIPS 203 builds a ciphertext, since the compression makes some encoded values more likely than others and a hop could otherwise count the real entries. Each hop decapsulates the front entry, folds the secret into its classical ECDH result, peels its layer with the hybrid keys and rotates the entry to the back. The list carries no key or MAC of its own, and its integrity comes from the hybrid onion MAC instead, so a tampered, reordered or dropped entry yields a wrong hybrid secret at that hop and the payment fails closed. The hybrid secret also becomes the hop’s incoming secret, so the return error onion and its attribution data inherit the protection. Blinded payment paths are built by the recipient instead of the sender, so the recipient protects them. When building a PQ blinded path, it encapsulates to each path hop’s ML-KEM key and folds the secrets into the route-blinding schedule, so the blinded node ids and the encrypted per-hop data are hybrid before the sender sees the path. The ciphertexts

reach the sender in the invoice record of Section IV-E and travel in a second fixed list of 10 slots beside the onion. A key exchange needs both endpoints to take part, so PQLN cannot force the hybrid onion on every route. Two configuration flags therefore decide when a node requires it. A sender builds the hybrid onion whenever every hop has a pinned ML-KEM key and otherwise falls back to a classical onion, unless the require_post_quantum_payments flag forbids the fallback. Similarly, the require_post_quantum_ inbound flag makes a forwarding or receiving node fail back any HTLC that arrives without the hybrid protection (Threat 5). V. S ECURITY A NALYSIS In this section, we show how PQLN addresses the threats of Section IV-A. We give one proposition per threat, each with a proof sketch that reduces its guarantee to the standard notions of ML-DSA and ML-KEM. A. Model and Assumptions We write (K, c) ← Encaps(ek) for ML-KEM-768 encapsulation, whose ciphertext c decapsulates to K under the decapsulation key dk, and Vf(pk, m, σ, ctx) for ML-DSA44 verification under the per-surface context string ctx. The hash H is SHA-256. A node N holds an ML-DSA key pair (pkN , skN ) and a static ML-KEM key pair (ekN , dkN ). The pin PinV [N ] denotes the pair (pkN , ekN ) that a verifier V stored on first sight, or ⊥ if V never saw N . Outside the transport, PQLN derives the hybrid secret s∗ = H(τ ∥ sc ∥ K)

(1)

under a per-surface tag τ wherever it folds a classical ECDH secret sc with an ML-KEM secret K. The transport folds K into Noise’s chaining key through HKDF instead. We model the adversary A of Section IV-A by giving it a discrete-logarithm oracle on secp256k1. It thus knows the secret key behind every public key and the shared secret of every ECDH exchange that it has observed. It also controls the network and runs nodes of its own, while the endpoints under analysis are honest. Assumption 1: ML-DSA-44 is existentially unforgeable under chosen-message attacks (EUF-CMA) and ML-KEM768 is indistinguishable under chosen-ciphertext attacks (INDCCA) against quantum adversaries, as the standards claim [7],

9

[8]. ChaCha20-Poly1305 is a secure authenticated cipher, and H, HMAC and HKDF behave as random oracles or pseudorandom functions, as Section IV-A assumes. Assumption 2: For every honest node N and verifier V with PinV [N ] ̸= ⊥, the pin holds the keys that N generated, and every offer that a payer holds carries the key that its payee committed. This trust-on-first-use assumption of Section IV-A holds when the announcement or the offer arrived either before a quantum adversary existed or over an authenticated channel such as a QR code scanned in person. Against a classical adversary, PQLN is at least as secure as vanilla Lightning, since every classical check stays in place and a message that must carry both signatures is unforgeable when either scheme is [34]. Moreover, (1) follows the randomoracle KEM combiner of Giacon et al. [35] with the ciphertexts left out of the hash. This is safe because ML-KEM decapsulation binds the shared secret to its ciphertext through reencryption [7] and a different ephemeral key yields a different ECDH secret. Cremers et al. formalize the former property as HON-BIND-K-CT, under which the output key of an honestly generated key pair determines the ciphertext, and report that the known attacks on ML-KEM’s binding need a maliciously formed key pair [36], which Assumption 2 excludes. The output of (1) thus stays random when either input secret is, so the propositions below address only the quantum adversary. B. Security Against the Threats Proposition 1 (Node impersonation): Under Assumptions 1 and 2, if a verifier V with PinV [N ] ̸= ⊥ accepts a node_announcement or channel_update attributed to an honest node N , then N produced it, except with probability at most AdvEUF-CMA ML-DSA (B) for an adversary B of similar running time. Proof: The verifier of Section IV-B accepts such a message only if every expected record is present, any carried key equals PinV [N ] and the ML-DSA signature verifies under pkN over the entire message, including the key records. The discrete-logarithm oracle lets A forge the ECDSA signature and set any feature bit, but neither enters this decision. A stripped record fails the first check, and a substituted key fails the second because the pin holds the keys of N by Assumption 2. What remains is a message that N never signed but that verifies under pkN and the gossip context, which B outputs as its forgery. Proposition 2 (Transport decryption): Let an honest initiator I hold ekR of an honest responder R under Assumption 2. Under Assumption 1, 1) the session keys of their hybrid handshake are indistinguishable from random for A even given all three ECDH secrets, 2) no party without dkR completes act two toward I, and 3) a later compromise of both static keys does not reveal the session keys. Proof: The chaining key absorbs the shared secrets Ks and Ke behind the ciphertexts cts and cte of Section IV-C between the three ECDH secrets. Replacing Ke by a random key changes the view of A by at most the IND-CCA advantage at eke . The chaining key has then absorbed a random secret that A does not hold, so the session keys that it yields are pseudorandom, which gives 1). This step rests on the hashobject result of Angel et al., who prove that the Noise hash

chain yields pseudorandom keys once it absorbs one input unknown to the adversary, and their argument covers hybrid patterns [22]. We do not restate their proof in the flexible ACCE model, so the proposition argues at the level of the chaining key only. The act two tag that I verifies is keyed after Ks has entered the chaining key. A party without dkR decapsulates an unrelated secret by implicit rejection, so it completes act two only by recovering Ks from cts or by forging the tag, which gives 2). Finally, Ke depends only on the per-connection ephemeral pair, so a later static compromise reveals nothing about it, which gives 3). Proposition 3 (Invoice forgery): Let a payer P hold an anchor pk ∗ for its payee under Assumption 2, namely PinP [N ] or an out-of-band key for BOLT 11 and the key committed in the offer for BOLT 12. Under Assumption 1, A makes P pay an invoice that the payee did not sign with probability at most AdvEUF-CMA ML-DSA (B). Proof: The pay paths of Sections IV-D and IV-E refuse an absent, malformed or invalid signature and a carried key that differs from the anchor. The payer therefore dispatches an HTLC only if Vf(pk ∗ , mI , σI , ctx) = 1, where mI covers the payment hash, the amount, the payment paths and any embedded key. Such a signature on an invoice that the payee never signed is a forgery, and the pairwise distinct contexts prevent a signature from one surface, including a static invoice, from verifying on another. The per-offer key of BOLT 12 also stays hidden from A, since its seed is an HMAC under the node’s symmetric offer key. Proposition 4 (Payment deanonymization): Consider a hybrid onion over n hops whose ML-KEM keys satisfy Assumption 2. Under Assumption 1, the per-hop keys of every hop are indistinguishable from random for A even given all per-hop ECDH secrets, with advantage at most n· AdvIND-CCA ML-KEM (B)+
256 qH /2 for qH random oracle queries. Proof: Hop i derives its keys from s∗i of (1) with (Ki , ci ) ← Encaps(eki ). A hybrid argument over the hops replaces each Ki by a random key at the cost of one INDCCA advantage. Each s∗i is then a random oracle output on an input that A guesses with probability at most qH /2256 per hop. From that point, the Sphinx analysis of Danezis and Goldberg [31] applies unchanged to the packet, and it covers blinded paths as well, since the route-blinding cascade applies (1) before it derives the blinded node ids. The ciphertext list carries no key or MAC of its own and its dummies follow the ciphertext distribution, so a single hop learns nothing from it beyond the fixed-size onion as long as ML-KEM ciphertexts are pseudorandom and hide their target key, which Maram and Xagawa proved for Kyber [37]. However, the list is rotated rather than re-randomized at each hop, so two colluding hops can match its contents and learn that they forward the same payment. Vanilla Lightning already leaks this linkage through the payment hash that every HTLC of a payment carries, so PQLN neither weakens nor improves the privacy of the onion against colluding hops. Finally, a tampered entry changes Ki by implicit rejection and fails the MAC check. Proposition 5 (Downgrade): Under Assumptions 1 and 2, A cannot make an anchored verifier process a gossip message or an invoice classically except by forging ML-DSA, nor make a

10

PQ port complete a classical handshake. Under the two flags of Section IV-F, a sender never dispatches a classical onion and a node never accepts one. Proof: The accept predicate of every signature surface depends only on the verifier’s local anchor and on ML-DSA verification, never on a feature bit. Since A rewrites messages but not the verifier’s storage, a message from an anchored peer is either verified under the anchor or refused, and Propositions 1 and 3 bound the chance that a forged message verifies. The transport offers no negotiation to rewrite, since the hybrid handshake runs on its own port with a fixed act layout. For the onion, the sender flag refuses any route with a hop that lacks a pinned key and the inbound flag fails back any HTLC without a ciphertext list, so a withheld gossip key or a stripped list stops the payment instead of degrading it. VI. E VALUATION This section describes the implementation and experiment setup of PQLN and presents the evaluation results. A. Experiment Setup and Metrics To evaluate the proposed design, we implemented it by modifying the rust-lightning [15] source code at commit 384e0d6 of its main branch (August 2026). The fork adds roughly 11,000 lines of code across 52 files, all gated behind a single Cargo feature named post-quantum. ML-DSA-44 and ML-KEM-768 come from the fips204 (v0.4.6) and fips203 (v0.4.3) Rust crates. With the feature disabled, the fork passes the complete upstream test suite. With it enabled, the fork also passes 99 added tests, 36 of which exercise the attacks and refusals analyzed in Section V. They cover substituted keys, stripped or tampered signatures and records, tampered or dropped ciphertexts and lists, and classical routes or HTLCs under the two flags of Section IV-F. The fork refuses each attack without altering state or moving funds. A variant of the fork6 makes the ML-DSA and ML-KEM sets selectable at build time and can replace ML-DSA with FN-DSA at degree 512 or 1024 through the fn-dsa (v0.4.0) crate. This variant serves the parameter set comparisons of Sections VI-B and VI-D and passes the same tests at all 15 pairings. The network experiments of Sections VI-C, VI-D and VI-E use real Lightning nodes against Bitcoin Core v31.17 in regtest mode. The nodes run pq-ldk-sample, our publicly available8 adaptation of LDK’s reference node ldk-sample [38] with commands and flags for the PQ functionality. From this source we built a vanilla binary that links the unmodified rust-lightning code at our fork’s base commit and a PQ binary that links our fork with the feature enabled, so any difference between them comes only from PQLN. A Python harness orchestrates the Bitcoin daemon and the nodes on a workstation with a 16-core AMD Ryzen Threadripper PRO 3955WX processor and 64 GB of RAM under Ubuntu 26.04. To assess PQLN, we use the following metrics: 1) Computational overhead which refers to the execution time of 6 https://github.com/ahmet-kurt/pq-rust-lightning/tree/configurable 7 https://bitcoincore.org/en/releases/31.1/ 8 https://github.com/ahmet-kurt/pq-ldk-sample

TABLE III E XECUTION T IMES OF THE C RYPTOGRAPHIC O PERATIONS IN M ICROSECONDS (M EAN AND S TANDARD D EVIATION OF 1000 RUNS ) Signatures Operation Key generation Signing Verification Key exchange Operation Key generation Encapsulation Decapsulation Hybrid secret fold

ML-DSA-44 131.4 ± 5.6 327.0 ± 222.5 103.4 ± 6.8

FN-DSA-512 2006.8 ± 576.4 215.6 ± 5.8 13.5 ± 0.9

ML-KEM-768 51.0 ± 1.9 55.3 ± 1.9 74.0 ± 2.6 0.4 ± 0.1

ECDSA Schnorr 19.3 ± 1.2 25.7 ± 1.2 20.3 ± 1.1 33.8 ± 7.1 33.5 ± 1.6 ECDH 19.3 ± 1.2 34.6 ± 1.6 34.6 ± 1.6 n/a

Gossip and BOLT 11 sign with ECDSA and BOLT 12 with Schnorr. All three classical schemes share one secp256k1 key generation, and one ECDH operation serves as both encapsulation and decapsulation.

the added cryptographic operations; 2) Payment latency which refers to the end-to-end delay of a payment measured at the payer; 3) Communication overhead which refers to the size increase caused by the added cryptographic material at the message and network scales; 4) Interoperability which refers to whether PQ and vanilla nodes can coexist and transact in every combination. The vanilla build serves as the baseline for all comparisons. B. Computational Overhead Analysis We first measured the execution times of the cryptographic operations added by PQLN. A timing test in the fork calls the production functions and runs each operation 1000 times on fresh inputs in a release build after a warmup. We repeated it three times with nothing else running and averaged the results. Table III presents them next to vanilla rust-lightning’s classical operations, and the variant supplied the FN-DSA-512 column and the other parameter-set timings below. As can be seen from Table III, every operation of the default sets completes well below a millisecond. The most expensive operation is ML-DSA signing with 0.33 ms on average, which is about 13 times slower than ECDSA signing. Its large standard deviation comes from rejection sampling. From these numbers, the hybrid handshake adds around 180 µs to the initiator and 130 µs to the responder, and a hybrid onion adds 55 µs per hop to the sender and 74 µs to each hop. A BOLT 12 payee spends around 460 µs per invoice to re-derive its per-offer key and sign. The larger parameter sets stay in the same range, since ML-DSA-87 signing averages 0.64 ms. FN-DSA-512 reverses this profile. It signs and verifies faster, but its key generation takes 2.0 ms with a large variance and 9.8 ms at degree 1024. A node generates its identity key once, so only a BOLT 12 payee pays this cost repeatedly, for every invoice. These costs are small compared to the delay of a payment, which we measure next. C. Payment Latency Analysis The ciphertext list of Section IV-F always carries 20 MLKEM-768 ciphertexts and therefore adds 21.8 kB to every update_add_htlc, so we measured its effect on the end-to-end delay of a payment. We built chains of one to three hops with vanilla nodes and again with PQ nodes, and the payer at one end recorded the delay from the start of route finding until

11

b PQLN relay budget

update_add_htlc ciphertext list

c

QR code capacity

LDK invoice cap

ML-DSA 10.5 10.7 10.8 12.2 12.6 12.9 65 13.1× 13.3× 13.6× 11.0× 11.4× 11.7×

BOLT 11 invoice, signature only

node_announcement records

ML-DSA 14.1 14.3 14.5 16.1 16.5 16.9 87 17.6× 17.9× 18.1× 14.6× 14.9× 15.3×

BOLT 12 offer, PQ blinded paths

channel_update record (+4 B for BOLT 12)

BOLT 12 refund, PQ blinded paths

BOLT 8 act two

1 kB

3 kB

10 kB 30 kB

15

FN-DSA 5.3 5.5 5.7 1024 6.6× 6.9× 7.1×

6.9 7.3 7.7 6.3× 6.6× 7.0×

512 768 1024

512 768 1024

10

5

0

ML-KEM set

BOLT 12 offer

BOLT 8 act one

4.5 4.9 5.3 4.1× 4.4× 4.8×

9.3 9.7 10.1 ML-DSA 7.9 8.1 8.3 44 9.9× 10.2× 10.4× 8.4× 8.8× 9.1×

BOLT 11 invoice, embedded key

update_add_htlc blinded tail list

Graph download Stored graph FN-DSA 3.3 3.5 3.7 512 4.2× 4.4× 4.6×

kB per channel

a

0

Added bytes per message

4000

8000

12000

Length (characters)

ML-DSA-44 (filled), 65, 87 FN-DSA-512, 1024 ML-KEM-512, 768 (filled), 1024 vanilla node range over the ML-KEM sets

Fig. 7. Communication overhead of PQLN at every ML-DSA, FN-DSA, and ML-KEM parameter set. (a) Bytes added per message. (b) Payment request lengths. (c) Gossip cost per channel for all 15 pairings, where each cell also gives the multiple of the vanilla cost of 0.8 kB (download) and 1.1 kB (stored graph) per channel. TABLE IV E ND - TO -E ND PAYMENT L ATENCY IN M ILLISECONDS (M EAN AND S TANDARD D EVIATION OF 50 PAYMENTS ) Loopback Hops Vanilla PQ 1 113 ± 44 98 ± 38 207 ± 57 193 ± 46 2 3 297 ± 54 306 ± 64

50 ms RTT, 10 Mbit/s 50 ms RTT, 1 Mbit/s Vanilla PQ Vanilla PQ 228 ± 39 252 ± 49 278 ± 49 438 ± 40 418 ± 67 456 ± 56 465 ± 65 818 ± 64 608 ± 91 768 ± 84 651 ± 71 1213 ± 79

it received the preimage. Every chain ran on the loopback interface and over a wide-area link emulated with netem, the Linux network emulator. The link has a 50 ms round-trip time and runs at 10 Mbit/s or at 1 Mbit/s, so the nodes pay the propagation delay and the size-dependent transmission time of an Internet path. The payer sent 50 invoice payments of 10,000 sat per configuration, and the payments on the chains of PQ nodes used pinned keys, signed invoices and hybrid onions. Table IV presents the results. On loopback, a vanilla payment takes around 0.1 s per hop, and PQLN changes this by at most 15 ms. The baseline itself comes from rust-lightning, which holds every incoming HTLC and processes them in batches at random intervals averaging 56 ms. At 10 Mbit/s, PQLN adds 19 to 53 ms per hop. Transmitting the list takes 17 ms at that rate. TCP also sends at most 10 segments after an idle period, and the message spans 16 of them at the link’s 1500-byte MTU, so the rest waits one round trip for an acknowledgment. At 1 Mbit/s, transmitting the list alone takes 174 ms, so PQLN adds 160 to 187 ms per hop and a three-hop payment takes 1.21 s instead of 0.65 s. D. Communication Overhead Analysis The main cost of PQLN is therefore communication. We measured it with the default parameter sets and repeated every measurement at the other NIST sets and with FN-DSA through the variant. Fig. 7 presents the results with filled markers for the default sets. Message Overhead: Fig. 7(a) shows how many bytes the PQ records add to each wire message, including the TLV record headers. With the default sets, a node_announcement grows by 4928 bytes, a channel_update by 2424 bytes and the two hybrid handshake acts by 2272 and 1088 bytes. The largest

overhead comes from the ciphertext list of the payment onion, which adds 21,770 bytes because it always carries 20 entries. The blinded tail list adds another 10,890 bytes when a payment ends in a PQ blinded path. The gossip records grow with the ML-DSA set, and the ML-DSA-87 records exceed the 8192byte relay budget of Section IV-B with ML-KEM-768 and ML-KEM-1024, so the variant doubles the budget for these two pairings. FN-DSA moves in the other direction, since its records add only 2759 bytes to a node_announcement and 670 bytes to a channel_update at degree 512. The ML-KEM set mainly affects the ciphertext lists, and the onion list grows from 15.4 kB with ML-KEM-512 to 31.4 kB with ML-KEM1024, still below Lightning’s 65,535-byte message limit. Payment Requests: Fig. 7(b) shows the lengths of the payment requests generated by our nodes, and they vary by a few characters depending on the payment amount. A vanilla BOLT 11 invoice is around 400 characters, whereas it becomes 4286 characters with only the ML-DSA signature and 6396 characters when the public key is also embedded. Similarly, an offer grows from 416 to 2528 characters because of its committed key, and to 4332 characters with PQ blinded paths. A refund keeps its 531 characters because its signature stays classical, and only PQ blinded paths enlarge it to 2323 characters. The payment requests face two hard limits: 1) rustlightning refuses to parse a BOLT 11 invoice longer than 7089 characters [15], and 2) a QR code holds at most 4296 alphanumeric characters [39]. Among the ML-DSA sets, only ML-DSA-44 keeps every payment request below the parser limit, and among the ML-DSA invoices only its signature-only invoice fits a QR code, with 10 characters to spare. Both FNDSA sets stay below the parser limit, and FN-DSA-512 with ML-KEM-768 fits every request into a QR code with room to spare. ML-DSA-44 is thus the only set of the published standard whose payment requests all remain usable, which supports the choice of Section IV. Gossip at Network Scale: Every joining node downloads and stores the announcements of all public channels and nodes, so we measured its download and its stored graph in real networks of 5 to 100 nodes with 10 to 200 public channels.

12

TABLE V I NTEROPERABILITY T EST M ATRIX B ETWEEN VANILLA (V) AND PQ (Q) N ODES (A LL S CENARIOS PASS ) Scenario S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S11 S12

Nodes V-V Q-Q Q-Q V-Q Q-Q-Q Q-V-Q Q-V, Q-Q V-Q, Q-Q V-V-V Q-Q-Q V-Q-Q Q-V-V

Functionality exercised Vanilla control with public channel, BOLT 11 both directions, keysend, BOLT 12 offer and refund, cooperative close Same operations with all five protected surfaces, from hybrid handshake and pinning to invoice, onion and offer protections BOLT 12 offer and refund with PQ blinded paths, covering message paths, payment paths and refund ciphertexts Mixed pair in both directions, where the vanilla node stores PQ gossip and every payment type completes classically Pin relay across the graph, two-hop hybrid onion with ciphertext rotation at the middle hop, hybrid error onion on a failure Vanilla hop stores but does not relay PQ announcements, so the endpoints complete a classical payment through it Sender running require_post_quantum_payments refuses the classical route and still pays its pinned peer Receiver running require_post_quantum_inbound fails back the classical HTLC and accepts the hybrid one Asynchronous payment control with a static invoice server and a held HTLC for an often-offline recipient ML-DSA-signed static invoice verified against the offer’s committed key before the held HTLC is released Vanilla sender on a PQ async offer fails closed before any HTLC is dispatched PQ sender pays a vanilla async offer classically

Each network has a ring topology with additional channels between random node pairs, and we built it with vanilla nodes and again with PQ nodes. After every node had learned the complete graph, a fresh observer node joined over the classical transport, so the two runs differed only in their gossip. We summed the observer’s incoming gossip until its graph was complete and read the size of its graph file after it shut down. Both costs grow linearly with the number of channels, and three repetitions produced identical byte counts because the message sizes are deterministic. Each channel adds 8111 bytes to the PQ download and 9687 bytes to the PQ graph file against 799 and 1102 bytes for vanilla, so a PQLN node downloads 10.2 times and stores 8.8 times the gossip data of a vanilla node. The two channel_updates of every channel dominate this cost, since their signature records account for 4848 of the 8111 bytes. Fig. 7(c) shows the same per-channel costs for all 15 pairings. They rise to 14.5 kB with ML-DSA-87 and ML-KEM-1024, or 18.1 times the vanilla download, and fall to 3.3 kB with FN-DSA-512 and ML-KEM-512, or 4.2 times. A PQLN node that joins today’s network of 33,000 public channels would therefore download around 270 MB and store a 320 MB graph file with the default sets, against 26 MB and 36 MB for a vanilla node. FN-DSA-512 in place of ML-DSA-44 lowers these figures to around 115 MB and 160 MB. Osuntokun projects a 29-fold growth for converting every gossip signature to ML-DSA-44 [13], whereas PQLN keeps the growth at tenfold because the largest gossip message, the channel_announcement, stays classical at 432 bytes. E. Interoperability Analysis Table V presents our 12 interoperability scenarios, which verify that PQLN nodes join the existing network and transact with vanilla nodes in every combination. Each scenario runs real nodes in the listed combination and performs the listed operations, and the node logs confirm whether every payment ran protected or classical. S1 and S9 are the vanilla controls, and S9 to S12 cover asynchronous payments, where a static invoice server answers for an often-offline recipient and the sender holds its HTLC until the recipient returns. S2, S3, S5 and S10 exercise all five protected surfaces between PQ nodes over one and two hops. In the mixed scenarios, a vanilla node accepts and stores the PQ announcements but does not relay them, so no pin forms across it and payments that involve it complete classically (S4, S6, S12). With the two flags of Section IV-F, the sender instead refuses the classical route but still pays its pinned

peer (S7), and the receiver fails back the classical HTLC but accepts the hybrid one (S8). S11 fails closed without a flag, because a vanilla sender copies the offer’s metadata record into its invoice request as BOLT 12 prescribes and the enlarged request no longer fits into the fixed-size onion of an asynchronous payment, which then aborts before any HTLC is dispatched. Every combination thus resolves to protected operation between PQ endpoints, classical operation whenever a vanilla node is involved, or a refusal before any funds move, and no payment got stuck. PQLN can therefore be deployed in today’s network without a coordinated upgrade. VII. D ISCUSSION AND L IMITATIONS The evaluation shows that computation is not the obstacle to PQ protection in Lightning. The cost lies in gossip instead, which grows about tenfold with ML-DSA-44 and about fourfold with FN-DSA-512. Our measurement covers the initial synchronization of a static graph, and the steady-state gossip grows as well, since every channel_update carries a 2424-byte signature record. Only nodes that synchronize the full graph pay this cost. For example, rust-lightning’s mobile wallets instead fetch a compressed and signature-free snapshot of the graph from a server through rapid gossip sync. Such a server can add the PQ keys to the snapshot, and its clients would trust it for the keys just as they already trust it for the graph. PQLN has several limitations. First, its key distribution relies on trust-on-first-use, so a node that first meets a peer after a cryptographically relevant quantum computer exists can pin an adversary’s key. PQLN also does not yet rotate pinned keys, although a node needs this after a key compromise or for a move to FN-DSA. Two additions can close these gaps without a consensus change: 1) a node_announcement record signed under the old pinned key can rotate a pin, and 2) a channel’s funding key can commit to its owner’s PQ keys just as Taproot commits to a script tree, so a late joiner can verify these keys against a funding transaction confirmed before such a computer exists. The on-chain commitment covers only nodes with public channels, and we leave both additions to future work. Second, some signatures stay classical because their verifier holds no trusted key for the signer, namely those on the invoices of an unannounced BOLT 11 payee and on the BOLT 12 invoice_request and its refund response. Third, phantom payments stay classical, since they are a rust-lightning-only feature rather than part of the BOLT specifications. Finally, the TLV types, invoice tags, and feature bits of PQLN are

13

experimental and still need assignment through the BOLT process. Our evaluation covers only rust-lightning nodes, and we defer the tests with other Lightning implementations to future work. VIII. C ONCLUSION In this paper, we proposed PQLN, which brings PQ security to the off-chain surfaces of the Lightning Network without changing Bitcoin. PQLN adds ML-DSA and ML-KEM alongside the existing secp256k1 cryptography of gossip, transport, payment requests, and payment onions. It distributes the PQ keys through LN’s own gossip with trust-on-first-use pinning and fits the large PQ material into the existing message formats. We analyzed the security of PQLN against a quantum adversary, implemented it in rust-lightning, and evaluated it with real Lightning nodes. The added cryptographic operations take at most 0.33 ms, and the main cost is a tenfold growth of gossip data with ML-DSA-44, or about fourfold with FNDSA-512. Upgraded and unmodified nodes interoperate in all 12 test scenarios, so PQ protection can begin at Lightning’s off-chain layer today, before Bitcoin completes its transition. R EFERENCES [1] P. W. Shor, “Polynomial-time algorithms for prime factorization and discrete logarithms on a quantum computer,” SIAM Journal on Computing, vol. 26, no. 5, pp. 1484–1509, 1997. [2] Google Quantum AI and Collaborators, “Quantum error correction below the surface code threshold,” Nature, vol. 638, pp. 920–926, 2025. [3] R. Babbush et al., “Securing elliptic curve cryptocurrencies against quantum vulnerabilities: Resource estimates and mitigations,” PRX Quantum, vol. 7, no. 3, p. 031001, 2026. [4] C. Chevignard, P.-A. Fouque, and A. Schrottenloher, “Reducing the number of qubits in quantum discrete logarithms on elliptic curves,” in Advances in Cryptology – EUROCRYPT 2026. Springer Nature Switzerland, 2026, pp. 371–401. [5] M. Mosca, “Cybersecurity in an era with quantum computers: Will we be ready?” IEEE Security & Privacy, vol. 16, no. 5, pp. 38–41, 2018. [6] D. Moody et al., “Transition to post-quantum cryptography standards,” National Institute of Standards and Technology, Tech. Rep., 2024. [Online]. Available: https://doi.org/10.6028/NIST.IR.8547.ipd [7] National Institute of Standards and Technology, “Module-latticebased key-encapsulation mechanism standard,” U.S. Department of Commerce, Standard, 2024. [Online]. Available: https://doi.org/10.602 8/NIST.FIPS.203 [8] ——, “Module-lattice-based digital signature standard,” U.S. Department of Commerce, Standard, 2024. [Online]. Available: https://doi.org/10.6028/NIST.FIPS.204 [9] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008. [Online]. Available: https://bitcoin.org/bitcoin.pdf [10] D. Aggarwal, G. Brennen, T. Lee, M. Santha, and M. Tomamichel, “Quantum attacks on Bitcoin, and how to protect against them,” Ledger, vol. 3, pp. 68–90, 2018. [11] H. Beast, E. Heilman, and I. Foxen Duke, “BIP 360: Pay-to-MerkleRoot (P2MR),” 2024. [Online]. Available: https://github.com/bitcoin/b ips/blob/master/bip-0360.mediawiki [12] J. Poon and T. Dryja, “The Bitcoin Lightning Network: Scalable off-chain instant payments,” 2016. [Online]. Available: https://lightnin g.network/lightning-network-paper.pdf [13] O. Osuntokun, “Post-quantum Lightning: Layer by layer,” 2026. [Online]. Available: https://delvingbitcoin.org/t/post-quantum-lightning -layer-by-layer/2479 [14] P.-A. Fouque et al., “Falcon: Fast-Fourier lattice-based compact signatures over NTRU,” 2020. [Online]. Available: https://falcon-sign. info/falcon.pdf [15] Lightning Dev Kit, “A highly modular Bitcoin Lightning library written in Rust. It’s rust-lightning, not Rusty’s Lightning!” 2026. [Online]. Available: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning

[16] I. Stewart et al., “Committing to quantum resistance: A slow defence for Bitcoin against a fast quantum computing attack,” Royal Society Open Science, vol. 5, no. 6, p. 180410, 2018. [17] M. Kudinov and J. Nick, “Hash-based signature schemes for Bitcoin,” 2025. [Online]. Available: https://eprint.iacr.org/2025/2203 [18] A. M. Levy, “Quantum-safe Bitcoin transactions without softforks,” 2026. [Online]. Available: https://github.com/avihu28/Quantum-Safe-B itcoin-Transactions [19] D. Stebila, S. Fluhrer, and S. Gueron, “Hybrid key exchange in TLS 1.3,” RFC 9954, 2026. [Online]. Available: https://www.rfc-editor.org/ info/rfc9954/ [20] P. Schwabe, D. Stebila, and T. Wiggers, “Post-quantum TLS without handshake signatures,” in Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security. ACM, 2020, pp. 1461–1480. [21] E. Kret and R. Schmidt, “The PQXDH key agreement protocol,” 2023. [Online]. Available: https://signal.org/docs/specifications/pqxdh/ [22] Y. Angel, B. Dowling, A. Hülsing, P. Schwabe, and F. Weber, “Post quantum Noise,” in Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security. ACM, 2022, pp. 97–109. [23] S. Ghosh and A. Kate, “Post-quantum forward-secure onion routing,” in Applied Cryptography and Network Security. Springer International Publishing, 2015, pp. 263–286. [24] A. Rial, A. Piotrowska, and H. Halpin, “Outfox: A postquantum packet format for layered mixnets,” in Proceedings of the 24th Workshop on Privacy in the Electronic Society. ACM, 2025, pp. 42–54. [25] M. F. Esgin, O. Ersoy, and Z. Erkin, “Post-quantum adaptor signatures and payment channel networks,” in Computer Security – ESORICS 2020. Springer International Publishing, 2020, pp. 378–397. [26] E. Tairi, P. Moreno-Sanchez, and M. Maffei, “Post-quantum adaptor signature for privacy-preserving off-chain payments,” in Financial Cryptography and Data Security. Springer Berlin Heidelberg, 2021, pp. 131–150. [27] A. Kiayias and O. S. T. Litos, “A composable security treatment of the Lightning Network,” in 2020 IEEE 33rd Computer Security Foundations Symposium (CSF). IEEE, 2020, pp. 334–349. [28] A. Kurt, K. Akkaya, S. Yilmaz, S. Mercan, O. Shlomovits, and E. Erdin, “LNGate2 : Secure bidirectional IoT micro-payments using Bitcoin’s Lightning Network and threshold cryptography,” IEEE Transactions on Mobile Computing, vol. 23, no. 5, pp. 6027–6044, 2024. [29] Lightning Network community, “BOLT: Basis of Lightning technology (Lightning Network specifications),” 2026. [Online]. Available: https: //github.com/lightning/bolts [30] T. Perrin, “The Noise protocol framework,” 2018. [Online]. Available: https://noiseprotocol.org/noise.html [31] G. Danezis and I. Goldberg, “Sphinx: A compact and provably secure mix format,” in 2009 30th IEEE Symposium on Security and Privacy. IEEE, 2009, pp. 269–282. [32] P. Wuille, “BIP 32: Hierarchical deterministic wallets,” 2012. [Online]. Available: https://github.com/bitcoin/bips/blob/master/bip-0032.mediaw iki [33] L. K. Grover, “A fast quantum mechanical algorithm for database search,” in Proceedings of the Twenty-Eighth Annual ACM Symposium on Theory of Computing. ACM, 1996, pp. 212–219. [34] N. Bindel, U. Herath, M. McKague, and D. Stebila, “Transitioning to a quantum-resistant public key infrastructure,” in Post-Quantum Cryptography. Springer International Publishing, 2017, pp. 384–405. [35] F. Giacon, F. Heuer, and B. Poettering, “KEM combiners,” in Public-Key Cryptography – PKC 2018. Springer International Publishing, 2018, pp. 190–218. [36] C. Cremers, A. Dax, and N. Medinger, “Keeping up with the KEMs: Stronger security notions for KEMs and automated analysis of KEMbased protocols,” in Proceedings of the 2024 ACM SIGSAC Conference on Computer and Communications Security. ACM, 2024, pp. 1046– 1060. [37] V. Maram and K. Xagawa, “Post-quantum anonymity of Kyber,” in Public-Key Cryptography – PKC 2023. Springer Nature Switzerland, 2023, pp. 3–35. [38] Lightning Dev Kit, “ldk-sample: Sample node implementation using LDK,” 2026. [Online]. Available: https://git.rust-bitcoin.org/lightningde vkit/ldk-sample [39] International Organization for Standardization, “Information technology — automatic identification and data capture techniques — QR code bar code symbology specification,” ISO/IEC, Standard, 2024. [Online]. Available: https://www.iso.org/standard/83389.html