Lightning Network and Quantum Computers: The HTLC Attack Surface

How Lightning Network Channels Create a Distinct Quantum Attack Surface

The Lightning Network processes Bitcoin payments off-chain through a network of bidirectional payment channels. As of mid-2026, approximately 5,300 BTC are locked in Lightning channels across roughly 60,000 active channels. Those funds sit in multisig funding outputs that expose public keys on-chain in a way that creates persistent quantum vulnerability distinct from base-layer Bitcoin.

Understanding this risk requires understanding how Lightning channels work at a cryptographic level, not just conceptually. The details matter because the attack surfaces are specific, the time windows are well-defined, and the migration path is significantly harder than base-layer post-quantum migration.

How Lightning Channel Funding Works Cryptographically

Every Lightning channel begins with a funding transaction. Two parties each contribute funds to a 2-of-2 multisig output on the Bitcoin base layer. The locking script for this output is a standard P2WSH (pay-to-witness-script-hash) wrapping a 2-of-2 OP_CHECKMULTISIG script.

When the channel is closed cooperatively, both parties sign a closing transaction that distributes the funds according to the final channel balance. When the channel is force-closed, one party broadcasts a commitment transaction unilaterally.

Here is where quantum exposure enters. The 2-of-2 multisig script contains two public keys: one from each channel participant. When the channel is opened, this script is not immediately visible (P2WSH hides the script). But when the channel is closed, the witness data reveals the full redeem script including both public keys. After any channel close, both participants' public keys are permanently on-chain.

For channels that remain open, the funding output's script hash is on-chain but the public keys are hidden. A quantum attacker cannot directly derive private keys from the P2WSH hash alone. The risk from open channels comes from a different mechanism.

HTLC Attack Vectors: The Three Specific Quantum Threats

Lightning payments route through hash-time-locked contracts (HTLCs). An HTLC is a conditional payment that can be claimed by the recipient if they reveal a preimage (the hashlock condition) within a specified number of blocks (the timelock condition). When HTLCs land on-chain during channel disputes, they create specific, bounded quantum attack windows.

Attack Vector 1: HTLC-timeout and HTLC-success transaction windows. When an HTLC is in-flight and a channel is force-closed, the HTLC appears as an output in the commitment transaction. Resolving this output requires one of two transactions: an HTLC-success transaction (recipient claims with the preimage) or an HTLC-timeout transaction (sender reclaims after the timelock expires). Both reveal the signing party's public key in the witness data. The timelock is typically 40 to 144 blocks (6 to 24 hours for HTLC-timeout), creating a defined window during which the public key is visible and the funds are claimable. A quantum computer that can derive a secp256k1 private key within 6 to 24 hours could intercept this window.

Attack Vector 2: Channel key reuse across generations. Lightning node operators commonly reuse the same node public key across multiple channel lifetimes. When a channel closes, the node's public key is permanently on-chain in the closing transaction witness. If the same key is then used in a new channel, an attacker has already harvested it. They can wait for a new commitment transaction to appear (during a future force-close) and construct a competing transaction using the derived private key before the honest party's HTLC-timeout or revocation sweep confirms. Node key reuse converts a bounded time-window attack into a persistent exposure equivalent to P2PK.

Attack Vector 3: Payment routing metadata and channel graph exposure. The Lightning network gossip protocol broadcasts channel announcements containing both channel endpoints' public keys, along with channel capacity and policy parameters. Every node on the network maintains this channel graph. A quantum attacker harvesting the gossip database has a comprehensive list of active Lightning node public keys, their channel balances (approximate), and their counterparty relationships. This is not an attack on funds directly, but it is an intelligence database that identifies high-value targets for quantum attacks as hardware matures. Routing nodes with large capacity and high connectivity are identifiable and prioritizable targets.

Commitment Transactions and Channel State Exposure

Each Lightning channel maintains a series of commitment transactions, one held by each party, reflecting the current channel balance. These commitment transactions are not broadcast unless the channel is force-closed. But they exist off-chain as signed Bitcoin transactions, and they include outputs paying to each party's public key or to P2WPKH addresses derived from those keys.

If a malicious counterparty broadcasts an old commitment transaction (attempting to steal funds by reverting the channel to an earlier state), the honest party must respond within a revocation timelock, typically 144 blocks (approximately 24 hours). This response transaction reveals the honest party's public key on-chain.

The revocation window is 24 hours. A quantum computer capable of breaking secp256k1 in under 24 hours could potentially allow the malicious broadcast to succeed by deriving the honest party's private key from the revealed public key and constructing a competing transaction before the honest party can respond.

This attack vector does not require the attacker to have a channel with the victim. It requires only that the attacker can monitor the mempool, observe a force-close transaction, and react faster than the timelock allows.

Layer 1 vs. Layer 2 Quantum Exposure: A Direct Comparison

The quantum exposure profile of funds on Lightning differs from the same funds held on the Bitcoin base layer in several important ways. The following table contrasts the two layers across the key dimensions of quantum risk.

The table shows that Lightning's quantum exposure is structurally more complex than base-layer Bitcoin. The longer timelock windows (6 to 24 hours vs 10 minutes) mean Lightning funds require a slower quantum computer to be at risk — which is also a harder problem to solve now. But the gossip database, historical channel closures, and key reuse practices create a persistent background exposure that does not exist for fresh P2WPKH addresses.

Why Lightning Migration Is Harder Than Base-Layer Migration

Base-layer Bitcoin is difficult to migrate to post-quantum signatures. Lightning Network migration is harder still, for several interconnected reasons.

First, there is no current post-quantum multisig standard for Bitcoin. The NIST-standardized ML-DSA (Dilithium) and SLH-DSA (SPHINCS+) are single-party signature schemes. Constructing a 2-of-2 threshold signature scheme from them for use in Lightning channels requires additional cryptographic research that is not yet complete.

Second, Lightning's BOLT specifications (Basis of Lightning Technology) would require updates across multiple layers: BOLT 2 (channel establishment), BOLT 3 (Bitcoin transaction and script formats), BOLT 5 (on-chain transaction handling), and BOLT 11 (invoice protocol). Every node and client implementation would need updates, and channels cannot be selectively upgraded while remaining open.

Third, the size overhead of post-quantum signatures is substantial. ML-DSA signatures are approximately 2,420 bytes compared to 64 bytes for Schnorr signatures. SPHINCS+ signatures are 7,856 to 49,856 bytes depending on the parameter set. Fitting post-quantum signatures into Bitcoin transactions for Lightning on-chain operations would either require increased transaction size limits (a consensus change) or use of the most compact available schemes.

What BIP-360 Means for Lightning

BIP-360 proposes P2QRH (pay-to-quantum-resistant-hash) as a new Bitcoin output type for post-quantum transaction authorization. Understanding what BIP-360 does and does not address for Lightning is essential for assessing the migration timeline.

What BIP-360 directly addresses: On-chain transaction authorization using post-quantum signatures. BIP-360 defines a new output type that commits to a hash of a post-quantum public key (ML-DSA, SLH-DSA, or FALCON). Spending a P2QRH output requires revealing the post-quantum public key and a valid post-quantum signature. This directly replaces the ECDSA-based spending mechanism for base-layer Bitcoin UTXOs.

What BIP-360 does not address directly: Lightning channel multisig. The 2-of-2 multisig construction at the heart of Lightning channels requires a threshold signature scheme, not a single-party signature scheme. BIP-360's P2QRH handles single-key spending. A post-quantum 2-of-2 Lightning channel would require either a post-quantum threshold signature scheme (not yet standardized) or a script-based approach where each party signs separately with their post-quantum key.

The script-based approach would work mechanically: a post-quantum 2-of-2 script could require two separate ML-DSA signatures in the witness. But this doubles the signature data on every channel close — two ML-DSA-44 signatures totaling 4,840 bytes, compared to two Schnorr signatures totaling 128 bytes. This creates significant on-chain transaction size pressure for Lightning channel operations.

The migration sequence: BIP-360 activation on the base layer is a prerequisite for Lightning migration. Until P2QRH outputs are recognized by the network, Lightning cannot transition to post-quantum channel funding outputs. After BIP-360 activates, the Lightning specification community would need to define post-quantum BOLT extensions. After those extensions are specified, all Lightning node implementations (LND, CLN, Eclair, LDK) would need to implement them. The full sequence realistically takes 3 to 5 years after BIP-360 activation. BIP-360 itself has not yet activated. The detailed BIP-360 implementation guide covers the base-layer migration mechanics.

The BTC Amount at Risk in Lightning Channels

The approximately 5,300 BTC in Lightning channels represents a small fraction of total Bitcoin supply. But the quantum risk profile is specific and different from base-layer risk in ways that matter for users who rely on Lightning for daily transactions.

Channel closure transactions that have already settled on-chain have their public keys permanently exposed. If those participants reuse the same keys in new channels (which some implementations have done historically), the keys are already known to any attacker monitoring the blockchain.

For open channels, the base risk is limited to the channel-close window. But the HTLC routing risk and the commitment transaction revocation window create additional exposure that does not exist for simple UTXO holders on the base layer.

Users routing significant BTC amounts through Lightning should be aware that each successful payment leaves a trail of on-chain HTLC resolution transactions when channels close. Evaluating your Lightning quantum exposure requires looking at channel history, not just current channel state.

Quantum Migration Timeline for Lightning

The following table outlines the realistic sequence of events required for a quantum-safe Lightning Network, from the current state through full migration. Timelines are estimates based on Bitcoin governance history and the technical dependencies involved.

This timeline is optimistic — it assumes BIP-360 proceeds without major governance disputes and that the Lightning specification community works in parallel on post-quantum BOLT extensions. Historical Bitcoin governance timelines suggest these phases could each take longer. The NIST 2030 ECDSA deprecation deadline and the U.S. federal 2031 PQC migration deadline both precede Phase 5. This gap is the core problem: Lightning's quantum migration will likely not be complete before the regulatory migration window closes.

What Would a Quantum-Safe Lightning Network Require?

A fully quantum-safe Lightning Network requires changes at every layer of the stack. On the base layer, Bitcoin would need to adopt a post-quantum signature scheme (the BIP-360 P2QRH proposal is the current leading candidate). Lightning's BOLT specifications would then need parallel updates using the same cryptographic primitives.

Key areas requiring new specifications include: post-quantum 2-of-2 threshold signatures for funding outputs, post-quantum HTLC constructions that preserve the hash-timelock logic with quantum-safe signature schemes, and revocation key derivation mechanisms that do not rely on elliptic curve Diffie-Hellman.

Research on post-quantum threshold signatures is active. NIST's ongoing threshold cryptography standardization project may produce relevant primitives, but a final standard is not expected until the late 2020s at earliest.

The practical implication: Lightning Network participants should treat their funds as carrying somewhat higher quantum risk than equivalent BTC held in single-key P2WPKH outputs, due to the additional on-chain exposure from historical channel operations and the more complex migration path. For Lightning specifically: keep channel counts manageable, avoid reusing node public keys across channel generations, and watch BIP-360 progress closely. A Lightning migration will follow base-layer migration, but it requires separate preparation and a longer timeline.

Frequently Asked Questions

Is the Lightning Network more quantum-vulnerable than on-chain Bitcoin?

Moderately yes, for three specific reasons. First, Lightning's HTLC and revocation timelocks create windows of 6 to 24 hours where public keys are on-chain and funds are at risk — longer than the 10-minute mempool window for base-layer transactions. Second, Lightning's gossip protocol publishes node public keys publicly, creating a harvesting database that does not exist for on-chain UTXOs. Third, node key reuse across channel generations turns closed-channel key exposure into persistent vulnerability. The 5,300 BTC in Lightning channels is a modest absolute amount, but each BTC carries higher structural exposure than the same BTC in a fresh P2WPKH output.

Can HTLCs be attacked by a quantum computer?

The hash preimage component of HTLCs (SHA-256 hashlock) is quantum-resistant at current parameter sizes — Grover's algorithm halves effective security, leaving SHA-256 at 128 bits of post-quantum security. The vulnerability is in the ECDSA keys used to authorize HTLC-success and HTLC-timeout transactions. When these transactions hit the mempool during channel disputes, the signing party's public key is revealed. A quantum computer that can break secp256k1 within the HTLC timelock window (6 to 24 hours) could construct a competing transaction claiming the funds. The hashlock is not the attack vector; the signature scheme is.

What does BIP-360 do for Lightning specifically?

BIP-360 proposes P2QRH (pay-to-quantum-resistant-hash) as a new output type for base-layer Bitcoin, replacing ECDSA with post-quantum signatures for on-chain UTXOs. It does not directly address Lightning. Lightning's 2-of-2 channel multisig requires threshold signature constructions that BIP-360 does not specify. BIP-360 is a prerequisite for Lightning's quantum migration — Lightning cannot adopt post-quantum channel types until the base layer supports them — but activating BIP-360 alone does not make Lightning quantum-safe. Separate BOLT specification updates are required, which depend on post-quantum threshold signature research that is not yet complete.

Should I close my Lightning channels before quantum computers are a threat?

Not immediately — no quantum computer can break secp256k1 today, and closing channels is not required before the threat materializes. However, there are prudent practices now: avoid reusing node public keys across new channel openings (use fresh keys per channel where your implementation supports it), avoid keeping large balances in channels where your historical key usage is extensive, and follow BIP-360 developments so you can migrate channel funds to P2QRH outputs promptly once that output type activates. The Bitcoin quantum safety guide covers the full timeline and when action becomes necessary.

What is the realistic timeline for a quantum-safe Lightning Network?

A fully quantum-safe Lightning Network requires BIP-360 base-layer activation (estimated 2027–2029), followed by post-quantum BOLT specification drafting (2028–2030), implementation across all major Lightning clients (2029–2031), and network transition as legacy channels are replaced (2031–2034). The realistic completion date for a fully quantum-safe Lightning Network is 2034 at the earliest under an optimistic governance scenario. This timeline falls after the NIST 2035 ECDSA disallowance deadline, meaning Lightning will likely be non-compliant with federal standards for some period during migration. Early preparation, parallel specification work, and governance momentum on BIP-360 are the critical path items.