Fixing the Lightning Network: A Protocol-Level Migration Roadmap

Introduction

The previous article established that Lightning’s quantum vulnerability is structural: seven protocol components expose public keys, the revocation system is tied to secp256k1 algebra, and fund security requires a Bitcoin base-layer consensus upgrade that Lightning’s developers cannot ship on their own. Application-layer protections can halt the Harvest Now, Decrypt Later threat to metadata. Protecting channel funds requires a soft fork.

This article is the migration roadmap. It covers every affected protocol layer in dependency order, from what can be deployed today (transport encryption) through what requires the most complex coordination (on-chain channel state and migration mechanics). Where working implementations or formal proposals exist, I reference them. Where open engineering questions remain, I flag them. The roadmap draws on three independent technical analyses of Lightning’s PQC migration path, my own assessment of the CRQC Capability Framework implications, and the Bitcoin Layer 1 migration roadmap that defines Lightning’s hard dependency.

The ordering matters. Metadata protection first, fund protection second, coercive policy last. That is the only sequence that closes the right risks in the right order.

Phase 1: Transport Encryption (BOLT 8)

Dependency: None. Can be deployed immediately.

Lightning’s transport layer is the highest-priority migration target because it addresses a threat that is already active. Every Lightning peer-to-peer connection uses Noise_XK_secp256k1_ChaChaPoly_SHA256. The symmetric cipher (ChaCha20-Poly1305) is quantum-safe. The ECDH key exchange on secp256k1 is not. State-level adversaries recording Lightning transport traffic today will be able to decrypt it retroactively when a CRQC becomes available.

The migration is a hybrid Key Encapsulation Mechanism (KEM). During the Noise handshake, nodes generate ephemeral key pairs using both secp256k1 and ML-KEM (FIPS 203). The initiating node encapsulates a shared secret against the responder’s ML-KEM public key while simultaneously performing a classical ECDH operation. Both shared secrets are concatenated and fed through HKDF to derive the session key: session_key = HKDF(classical_ecdh_secret || ml_kem_secret).

The hybrid construction ensures security if either primitive is independently broken. If ML-KEM turns out to have a flaw, the classical ECDH still protects. If a quantum computer breaks secp256k1, the ML-KEM encapsulation still protects. This matches the security model recommended by CNSA 2.0 and NIST’s transitional guidance.

BOLT 8 already has a handshake version byte, and unknown versions are rejected. A new hybrid transport handshake version can be defined without breaking backward compatibility. Nodes signal PQ transport capability through a feature bit in node_announcement messages. If both peers support it, they use the hybrid handshake. If either peer lacks support, they fall back to classical Noise_XK.

The operational impact is minimal. ML-KEM public keys are 800 bytes (ML-KEM-512) to 1,568 bytes (ML-KEM-1024), and ciphertexts are comparably sized. This adds a one-time cost to the handshake but does not affect per-message throughput once the session is established. ChaCha20-Poly1305 continues to handle bulk encryption at full speed.

This phase should be the immediate priority for LND, Core Lightning (CLN), Eclair, and LDK implementation teams. It requires no Bitcoin consensus changes, no BOLT specification rewrites beyond BOLT 8 and BOLT 9 (feature bits), and no coordination with the broader Bitcoin community. It neutralizes the HNDL threat from the moment of deployment.

Phase 2: Onion Routing (BOLT 4)

Dependency: Phase 1 (transport) should be deployed first, but routing migration can proceed in parallel.

Lightning’s Sphinx-based onion routing uses ECDH at every hop to derive shared secrets and applies elliptic-curve scalar blinding to the ephemeral onion key to prevent packet linking between hops. Both operations depend on secp256k1.

A pure “swap ECDH for ML-KEM” patch is insufficient. Sphinx version 0 also depends on the algebraic structure of elliptic curve points for the blinding factor that ensures bitwise unlinkability between hops. ML-KEM has no analogous algebraic blinding operation. A drop-in replacement would break the unlinkability property.

Two migration approaches are available, and the pragmatic path uses both in sequence.

Near-Term: Hybrid Onion

The first deployable step is a hybrid onion packet that carries enough extra per-hop material to derive hop secrets from both classical (ECDH) and post-quantum (ML-KEM) sources. The combined secret is used to encrypt each layer. An adversary who can break secp256k1 but not ML-KEM cannot reconstruct the routing path from the captured packet.

The hybrid approach increases packet size. The current Sphinx specification mandates a fixed 1,300-byte routing packet regardless of hop count. ML-KEM ciphertexts of 768-1,568 bytes per hop would shatter this constraint. The hybrid onion must either increase the maximum packet size (requiring coordination across all routing nodes) or reduce the maximum hop count to fit within a larger but still fixed packet size.

This is a meaningful engineering tradeoff, not a showstopper. The hybrid onion reduces HNDL exposure for routing metadata immediately, even though it does not achieve the clean unlinkability properties of a purpose-built post-quantum routing protocol.

Medium-Term: Outfox or KEM-Based Routing

For the longer term, a research paper by Ando and Lysyanskaya proposes Outfox, a routing packet format designed from the ground up for post-quantum security. Outfox eliminates the need for interactive key exchange at every hop. Instead, the sender encapsulates routing instructions and ephemeral symmetric keys directly against each recipient’s long-term ML-KEM public key (retrieved from the gossip network). The per-hop header structure is compact, and the protocol has been formally proven secure within the Universal Composability (UC) framework.

Outfox requires a major, backward-compatible update to BOLT 4. During the transition, sending nodes must support both routing formats: Outfox onions for routes composed entirely of PQ-upgraded nodes, and legacy Sphinx onions for routes that include classical infrastructure. The privacy implication of a mixed network is worth noting: if only a fraction of the network supports Outfox, the anonymity set for PQ-routed payments is smaller than for classical-routed payments. As adoption grows, the anonymity set converges.

The transition from Sphinx to Outfox or a similar KEM-based format (neither of which is on a Lightning standards track today) is a multi-year research and development process. The hybrid onion is the pragmatic first step; Outfox is the architecturally clean destination.

Phase 3: Gossip Protocol (BOLT 7)

Dependency: Can proceed in parallel with Phases 1 and 2.

The gossip protocol is where post-quantum signature sizes create the most visible network-wide impact. Current gossip traffic runs approximately 103 MB per day with a 200-second convergence delay. A channel_announcement carries four signatures (two node signatures, two Bitcoin signatures). A node_announcement carries one. A channel_update carries one.

Replacing 64-byte signatures with post-quantum equivalents multiplies every message. The marginal payload increase from signatures alone: roughly 2.7 KB per channel_announcement with FN-DSA-512, roughly 13.2 KB with ML-DSA-65, and roughly 31.4 KB with SLH-DSA-128s. Multiply across the full network’s daily message volume and the result is multi-gigabyte daily bandwidth requirements under naive flood-fill propagation. That would structurally centralize the network by pricing out lightweight nodes, mobile wallets, and users in bandwidth-constrained regions.

Mitigation Architecture

The gossip layer cannot absorb PQ signatures through brute force. It requires architectural changes to how the network distributes topology information.

Server-assisted synchronization becomes mandatory infrastructure. Protocols like Rapid Gossip Sync and LNsync provide server-assisted gossip synchronization. Rather than downloading and independently verifying every individual channel update, nodes query a semi-trusted server or Lightning Service Provider (LSP) for a cryptographically verifiable snapshot of the network state delta. LNsync compresses 24 hours of standard updates into roughly 5.7 MB of uncompressed data, deliverable in seconds. These protocols exist today as optional optimizations for mobile user experience. In a post-quantum environment, they become essential infrastructure for any node that cannot handle multi-gigabyte daily gossip downloads.

Rate limiting and anti-jamming enforcement. Larger signatures increase the verification cost per gossip message, amplifying denial-of-service risk. BOLT 7 will need strict rate-limiting heuristics and potentially upfront fee requirements for relaying PQ-sized announcements. Nodes should require cryptographic proof of channel ownership (via the funding output) before agreeing to relay large PQ announcement messages.

BOLT 12 (Offers) reduces gossip dependency. The BOLT 12 specification introduces a more flexible invoicing mechanism where payment negotiation happens through direct peer-to-peer messaging rather than broadcast gossip. By shifting metadata exchange from the flood-fill gossip layer to targeted communication, BOLT 12 reduces the baseline gossip volume that must carry PQ-sized signatures.

Gossip identity migration. node_announcement and channel_announcement messages should gain PQ signature TLVs (Type-Length-Value extensions) and a versioned PQ node identity. During transition, verifying nodes should check both classical and PQ signatures when the sender advertises PQ support. Routing algorithms should prefer channels whose endpoint nodes are fully hybrid-capable, creating an organic incentive for node operators to upgrade.

Compact signatures matter more for gossip than for any other Lightning function. FN-DSA-512’s 666-byte signatures versus ML-DSA-65’s 3,309-byte signatures produce a 5x difference in per-message overhead, compounded across every message sent by every node on the network. If FN-DSA reaches FIPS finalization with adequate implementation quality, it becomes the strongly preferred choice for gossip authentication. If it does not, ML-DSA-44 (2,420-byte signatures) combined with aggressive server-assisted sync provides a workable, if expensive, alternative.

Phase 4: Funding Transactions and Multisignature

Dependency: Requires Bitcoin Layer 1 soft fork (BIP-360 or equivalent).

This is the load-bearing dependency. Everything above Phase 4 can be deployed at the Lightning application layer without waiting for Bitcoin consensus changes. Everything from Phase 4 onward requires that Bitcoin consensus can verify post-quantum signatures.

The current Lightning funding output is a P2WSH 2-of-2 multisig: 2 <pubkey1> <pubkey2> 2 OP_CHECKMULTISIG. A PQ-capable funding output must use the new witness/script path defined by BIP-360 or a similar proposal.

The Hybrid Authorization Model

During the transition period, the funding output’s spending condition must require both classical and PQ authorization, not either/or. This is a critical design choice. If a funding output can be spent by “classical OR PQ,” a quantum attacker simply takes the classical branch. The correct security model during transition is AND: the spend must include a valid Schnorr signature AND a valid ML-DSA signature from each participant.

The four-signature hybrid spend for a 2-of-2 channel looks like: Alice’s classical signature AND Alice’s PQ signature AND Bob’s classical signature AND Bob’s PQ signature. This doubles the signature burden compared to today. The fee cost is real:

(These figures represent a lower-bound estimate covering the additional PQ signatures only, excluding PQ public keys, script hashes, and control block data revealed in a P2MR script-path spend. The total on-chain cost will be moderately higher.)

The fee impact is proportionally smaller for larger channels. On a 10,000,000 sat channel (~0.1 BTC), the FN-DSA-512 hybrid overhead is 0.03% of channel value per on-chain settlement at 10 sat/vB. On a 1,000,000 sat channel, it rises to 0.30%. ML-DSA-65 is roughly 5x more expensive. SLH-DSA is prohibitive for any Lightning use case. Migration should begin with higher-capacity channels where the fee burden is proportionally negligible.

Taproot Integration

BIP-360’s P2MR (Pay-to-Merkle-Root) design is well suited for Lightning’s needs. The funding output commits only to the Merkle root of a script tree, with no key-path spend. Each script leaf can contain a different spending condition: a hybrid authorization leaf for cooperative close, a delayed-settlement leaf for unilateral close, HTLC-specific leaves for pending payments. Only the leaf actually used at spend time is revealed on-chain.

This hides the PQ signature verification logic (and its size) in the Merkle tree during normal channel operation. The full witness bloat penalty applies only when the channel closes uncooperatively, localizing the cost to dispute resolution rather than spreading it across every channel’s on-chain footprint.

Lattice-Based Key Aggregation

Research into lattice-based multisignature schemes offers a future optimization path. Recent work demonstrates that multiple lattice public keys can be aggregated into a single public key with a single signature, potentially achieving 1-round signing (improving on MuSig2’s 2-round requirement). The estimated combined size for an aggregated PQ multisig is roughly 4,096 bytes, still large by classical standards but a meaningful compression compared to concatenating independent signatures.

Current lattice multisig constructions require a trusted third party to generate a public parameter set (a shared matrix). For decentralized systems, this raises collusion concerns. Future implementations may need to embed the full matrix in the public key itself, increasing size but eliminating the trust dependency. This is an area of active research, not a deployable solution today.

Phase 5: Channel State, Commitment Transactions, and HTLCs (BOLT 2/3)

Dependency: Phase 4 (requires PQ-capable funding output on Layer 1).

Commitment Transaction Redesign

Commitment transactions are held off-chain and continually updated between peers. The larger ML-DSA signatures embedded within them do not hit the Bitcoin blockchain until the channel closes. Off-chain, the primary constraint is signing speed (for rapid state updates during high-volume routing) and the computational cost of verification (for watchtowers that must validate breach remedies under time pressure).

ML-DSA-65 signs in under a millisecond and verifies in 0.14 milliseconds on ARM hardware, faster than ECDSA’s 0.88 milliseconds for verification. The signing speed is adequate for Lightning’s update rate. The verification speed is favorable. The constraint is not computation; it is the increased size of each pre-signed state object stored by the node and its watchtower.

The Revocation Redesign

This is where the deepest architectural change lives. Current Lightning derives keys like localpubkey and delayedpubkey from basepoints using secp256k1-specific scalar multiplication: key = basepoint + SHA256(per_commitment_point || basepoint) * G. The revocationpubkey uses an even more complex two-point, two-scalar formula: revocation_basepoint * SHA256(revocation_basepoint || per_commitment_point) + per_commitment_point * SHA256(per_commitment_point || revocation_basepoint). This algebra has no post-quantum analogue.

The recommended replacement retires the elliptic curve algebra while preserving the ratchet mechanism that underpins Lightning’s penalty enforcement. The new model uses a state-secret schedule that derives independent per-state artifacts from a ratcheting secret tree:

• Per-state delayed-settlement authorization material
• Per-state remote-settlement authorization material
• Per-state HTLC authorization material
• Per-state revocation secret hash commitments

In current Lightning, BOLT 2’s revoke_and_ack message exposes the per_commitment_secret and provides the next per_commitment_point. In a PQ channel, that secret becomes a direct input to revocation unlocking rather than an input to a point tweak. The immediate penalty branch in to_local and HTLC second-stage outputs is unlocked by a revocation secret hash preimage plus PQ/hybrid signature, not by a tweaked revocationpubkey.

This preserves Lightning’s security intuition (publish an old state and the counterparty punishes you immediately) without requiring a future PQ signature family to replicate secp256k1 point arithmetic. All per-state delayed and HTLC public keys are derived off-chain and committed explicitly or by hash, not by on-chain algebraic tweak rules.

HTLC Redesign

HTLC scripts change in two ways. First, every classical OP_CHECKSIG operation becomes a PQ or hybrid signature verifier, referencing the keys hidden in the Taproot/P2MR script tree. Second, every penalty branch that currently depends on revocationpubkey must instead depend on a revealed revocation secret or a witness item derived from it.

The hash lock mechanism (SHA-256 preimage revelation) remains unchanged and quantum-safe. The second-stage HTLC-timeout and HTLC-success transactions should remain because they decouple to_self_delay from HTLC timeout semantics, a rationale that still applies under PQ. The default cltv_expiry_delta and to_self_delay values for PQ channels should be empirically recalibrated upward during signet testing, because larger witnesses take longer to propagate and confirm.

The PTLC Problem

The Bitcoin developer ecosystem has been moving toward Point Time-Locked Contracts (PTLCs) as a superior replacement for HTLCs. PTLCs use Schnorr adaptor signatures to improve payment privacy, reduce block space usage, and prevent wormhole attacks. Adaptor signatures are deeply tied to the algebraic properties of elliptic curves.

Post-quantum adaptor signatures based on lattice assumptions are mathematically complex and experimental. Theoretical frameworks for post-quantum adaptor signatures and payment channel networks have been proposed in recent cryptography symposiums, but they remain far from production-ready. Lightning may need to fall back to classical HTLCs with hash locks during the initial PQ migration, deferring the PTLC upgrade until lattice-based adaptor signatures mature. This is a temporary regression in payment privacy that the community should accept rather than delaying the PQ migration for a combined PTLC+PQ upgrade.

Phase 6: The Migration Vehicle — Channel Splicing

Dependency: Phase 4 (requires PQ-capable funding output on Layer 1).

If the network forced simultaneous closure and reopening of all channels to execute the PQ migration, the consequences would be severe: two on-chain transactions per channel (one close, one PQ-enabled open), each larger than current transactions due to PQ signatures, hitting the Bitcoin base layer simultaneously. Fee market spikes, capital locked during confirmation, routing capacity disrupted network-wide.

Channel splicing provides the alternative. Splicing allows nodes to change the capacity of an existing channel without closing it entirely, by generating a new funding transaction while maintaining off-chain routing capabilities during the confirmation period.

For the PQ migration, a “Splice-to-PQC” operation proceeds:

1. Alice and Bob negotiate a splice operation over their active classical channel.
2. Both nodes generate new hybrid (classical + PQ) key pairs.
3. The splice transaction spends the classical 2-of-2 funding UTXO and sends the balance to a new hybrid P2MR 2-of-2 UTXO.
4. While the splice transaction awaits confirmation, Alice and Bob continue routing payments by maintaining dual off-chain states mapped to both the old funding output (until the splice confirms) and the new PQ funding output (after confirmation).

Splicing halves the required on-chain transactions compared to close-and-reopen. It preserves routing liquidity and network connectivity throughout the migration. Lightning wallet implementations (LND, CLN, Eclair, LDK) should automate this process in the background, making the cryptographic transition largely invisible to end users.

The splice-based migration creates natural prioritization: high-value routing nodes and liquidity providers splice first (the fee burden is proportionally negligible on large channels), followed by medium-capacity channels, with the long tail of small personal channels migrating last. Fee pain scales with witness size, not with channel value, so larger channels have every economic incentive to migrate early.

Phase 0: Crypto-Agility Foundations

Dependency: None. Should begin immediately, in parallel with Phase 1.

Before any of the above changes can be deployed, Lightning implementations need preparatory work that makes them capable of handling PQ-era data structures even if they do not yet use them.

Feature bit negotiation (BOLT 9). New feature bits (proposals have suggested bits 100 and 101) signal support for hybrid channel negotiation and PQ routing. When two peers both signal PQ support, they use the hybrid handshake, PQ-capable gossip, and PQ channel types. When an upgraded node connects to a legacy peer, it falls back to classical protocols. Without this negotiation mechanism, the network risks hard partitioning into PQ and classical segments with no routing connectivity between them.

PSBT extensions. BIP 174 (Partially Signed Bitcoin Transactions) provides the extensible format for offline and multi-party signing. BIP 371 demonstrates the exact pattern Bitcoin used to add Taproot-specific signing fields. The PQ migration should define new PSBT key types for PQ signatures, PQ public keys, algorithm identifiers, witness-leaf data, and hybrid signing requirements. External signers and hardware wallets need these extensions to participate in PQ channel operations.

Watchtower schema redesign. Current watchtowers store fixed-size encrypted blobs for each channel state. With PQ/hybrid channels, each blob grows by several kilobytes. Storing a full breach-remedy package for every state becomes expensive. Tower protocols should be redesigned around encrypted breach templates, per-state key references, or delta-compressed witness construction rather than raw full-transaction duplication. The draft BOLT 13 model needs to account for PQ witness sizes.

Backup format versioning. Static Channel Backups (SCBs) and equivalent formats must record the channel’s cryptographic policy: which signing algorithms are in use, what the revocation-hash logic is, which watchtower endpoints support the channel’s format, and any external-signer references needed to assemble a sweep. A backup that does not state the cryptographic policy of the channel will fail at the moment it is needed most.

Algorithm Selection for Lightning: A Function-Specific Assessment

Different Lightning functions have different optimization targets. No single PQ algorithm is optimal across the full protocol stack. The recommended approach uses different algorithms for different functions:

FN-DSA’s compact signatures (roughly one-third the size of ML-DSA-44) make it the preferred choice wherever on-chain footprint or network bandwidth dominates the tradeoff. The implementation complexity and FIPS timeline uncertainty mean ML-DSA serves as the fallback baseline for every function where FN-DSA is recommended. SLH-DSA’s role is as a conservative hedge: available in a P2MR script tree leaf as an emergency spending path that does not share lattice-based mathematical foundations with ML-DSA or FN-DSA.

BIP-360’s Merkle tree structure enables this multi-algorithm approach. A single P2MR funding output can contain an ML-DSA cooperative close leaf, an FN-DSA unilateral close leaf, and an SLH-DSA emergency recovery leaf. Only the leaf exercised at spend time is revealed. Crypto-agility is built into the output architecture.

The Timeline

Assembling these phases into a realistic schedule:

Phases 0-3 can begin immediately and proceed in parallel. They are entirely within Lightning’s scope and require no Bitcoin consensus changes. The exit criterion for Phases 1-3 combined: interoperability across at least two Lightning implementations (LND, CLN, Eclair, or LDK) on regtest or signet.

Phase 4 is the bottleneck. It depends on the Bitcoin BIP-360 soft fork activation, which in turn depends on Bitcoin’s governance coordination. The Lightning community should prototype the new channel type on signet in parallel with the BIP-360 review process, so that the moment the soft fork activates, the Lightning implementation is ready for mainnet opt-in rollout.

Phase 5 follows Phase 4 by approximately one year of implementation and testing. Phase 6 (splicing-based migration of existing channels) is an open-ended process that can begin as soon as the new channel type is available and should proceed organically as node operators upgrade.

The full sequence, from immediate transport upgrades through mainnet-ready PQ channels, spans roughly 4-6 years under optimistic governance assumptions. The binding constraint is not Lightning engineering. It is the Bitcoin soft fork timeline.