Dr. Sarah ChenHow 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 Time Locks and the Specific Quantum Attack Window
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 an HTLC is in-flight, it appears as an additional output in the off-chain commitment transaction held by both channel parties. If the HTLC needs to be resolved on-chain (during a channel force-close while an HTLC is pending), the HTLC output and its conditions appear in the blockchain. The transaction that spends an HTLC output reveals the public key of the party claiming it.
The timelock creates a specific window: the HTLC must be claimed within a defined number of blocks, typically 40 to 144 blocks (roughly 6 to 24 hours). During the period when the claiming transaction is in the mempool, the public key is visible. A quantum computer that can break a 256-bit elliptic curve key in under 6 hours could intercept HTLC claims on-chain.
That threshold, breaking secp256k1 in under 6 hours, is far beyond any plausible near-term quantum hardware. But it is a bounded target: if quantum hardware reaches 10-minute key derivation (sufficient to attack base-layer Bitcoin), the HTLC timelock window offers meaningfully more time. The attack is harder, not impossible.
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.
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 8,080 to 50,000 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.
The Bitcoin post-quantum migration plan treats base-layer P2QRH output types as the first priority. Lightning migration sits in a later phase with dependencies on base-layer changes that have not yet been finalized.
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.
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. The broader quantum risk landscape for DeFi and payment protocols covers related issues across other Layer 2 systems.
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.
