Core Lightning 26.06's Quantum-Resistant Channels: What They Actually Protect

Core Lightning's 26.06 release, codenamed "Quantum-Resistant Lightning Channel," introduced experimental support for post-quantum cryptography in Lightning channel establishment. Meanwhile, academic researchers published PQLN, a hybrid post-quantum extension covering nearly every off-chain surface of the Lightning protocol. Together, these efforts represent the first concrete steps toward quantum-hardening Bitcoin's most widely used Layer 2.

But there is a critical gap. On-chain Bitcoin transactions still rely on elliptic curve cryptography that a sufficiently powerful quantum computer could break. Post-quantum Lightning channels protect the off-chain layer while leaving the foundation exposed. Understanding exactly what is protected, and what is not, matters for anyone building on Bitcoin's Layer 2 stack.

What Core Lightning 26.06 Actually Shipped

The Core Lightning 26.06 release from Blockstream shipped in June 2026 with several major changes: xpay became the default payment handler, the bwatch block-watching plugin was introduced, and a createproof command was added for BOLT12 payment proofs. The release also widened the channel-closure dispute window from 12 to 72 blocks.

The quantum-resistant channel feature uses a hybrid design: classical Schnorr and ECDSA signatures remain in place for backward compatibility, while a post-quantum key exchange layer is added on top for new channel types. This means that channel establishment between two CLN 26.06 nodes can use post-quantum key encapsulation to protect the initial handshake, while still producing standard on-chain outputs that the rest of the network recognizes.

The feature is experimental. Blockstream's quantum roadmap page indicates that extending post-quantum signing to Lightning channels still requires BOLT-specification coordination and a channel commitment upgrade path. In other words: the 26.06 release is a foundation, not a finished migration.

What "hybrid" means in practice: A hybrid post-quantum scheme runs classical and post-quantum algorithms in parallel. If the post-quantum algorithm turns out to have a flaw, the classical algorithm still provides security. If a quantum computer breaks the classical algorithm, the post-quantum one provides protection. You get the security guarantees of whichever algorithm survives.

The Threat Model: Harvest Now, Decrypt Later

The quantum threat to Lightning is not that someone will break your channels tomorrow. The danger is harvest-now-decrypt-later (HNDL): adversaries record encrypted traffic and signed transactions today, then decrypt them once quantum computers become powerful enough.

Lightning's Noise protocol transport layer uses Curve25519 for key agreement. An adversary who records the handshake can, with a future quantum computer, derive the session keys and decrypt every message exchanged during that session. This exposes channel state updates, HTLC details, payment amounts, and routing information.

What HNDL Exposes in Lightning

• Channel state and balance updates between peers
• Payment preimages and hash values in HTLCs
• Routing decisions and fee structures in onion-routed messages
• Invoice details including amounts and descriptions
• Node identity keys published in gossip announcements

Post-quantum channel establishment directly addresses this threat by making the initial key exchange resistant to quantum decryption. Even if an adversary records the handshake, they cannot derive session keys using Shor's algorithm.

PQLN: The Academic Approach

In September 2026, researchers from East Texas A&M University and collaborating institutions published PQLN: Post-Quantum Security for the Bitcoin Lightning Network's Off-Chain Surfaces, a more comprehensive approach to quantum-hardening Lightning. While CLN 26.06 focuses on channel establishment, PQLN covers nearly the entire off-chain protocol stack.

What PQLN Protects

PQLN uses lattice-based algorithms from NIST's post-quantum standards: ML-DSA (formerly CRYSTALS-Dilithium) for digital signatures and ML-KEM (formerly CRYSTALS-Kyber) for key encapsulation. The implementation covers five BOLT specifications:

Each node publishes its ML-DSA and ML-KEM public keys inside its signed node_announcement message. Peer nodes pin these keys on first contact, establishing a trust-on-first-use model similar to SSH.

Performance Overhead

The PQLN prototype, implemented as roughly 11,000 lines of Rust code added to the LDK (rust-lightning) codebase, introduces measurable but manageable overhead. The additional computation for post-quantum operations adds under 0.33 milliseconds per payment: a negligible cost for individual transactions.

Bandwidth is a different story. The default ML-DSA-44 plus ML-KEM-768 configuration increases gossip downloads by approximately 10.2 times and stored graph data by approximately 8.8 times. A new node performing initial sync would download roughly 270 MB of gossip data compared to 26 MB on a standard node.

Switching to FN-DSA-512 (a variant of the Falcon algorithm) reduces the overhead to approximately 4 times, making it more practical for bandwidth-constrained mobile nodes. Interoperability testing showed zero stuck payments when mixing upgraded and legacy nodes.

The bandwidth tradeoff: Post-quantum public keys and signatures are dramatically larger than their classical counterparts. An ML-DSA-44 public key is 1,312 bytes versus 32 bytes for a Schnorr key. An ML-DSA-44 signature is 2,420 bytes versus 64 bytes for Schnorr. This size increase ripples through every protocol message that carries cryptographic material.

What Post-Quantum Lightning Does Not Protect

The most important limitation of any Lightning-layer quantum defense is that it cannot protect the base layer. Bitcoin's security model relies on secp256k1 elliptic curve cryptography for transaction signing. Every on-chain transaction, including Lightning channel opens, closes, and force-closes, uses ECDSA or Schnorr signatures that a quantum computer running Shor's algorithm could forge.

The On-Chain Exposure

Lightning channels are anchored to on-chain UTXOs. Even with quantum-resistant off-chain communication, the channel's funding transaction and all potential closing transactions remain quantum-vulnerable. A quantum adversary could:

• Derive private keys from public keys exposed during on-chain spends
• Forge signatures to steal funds from channel outputs
• Intercept and redirect force-close transactions

This creates a layered security model where the off-chain protocol may be quantum-safe while the on-chain settlement layer is not. Fixing this requires changes to Bitcoin's consensus rules, not just Lightning software updates.

Quantum-Resistant Lightning vs. Quantum-Resistant Bitcoin

Bitcoin's On-Chain Quantum Preparedness: BIP-360 and BIP-361

Fixing the base layer requires consensus changes, and two draft BIPs have been proposed. Understanding them is essential context for evaluating Lightning's quantum defenses, because Lightning channels ultimately settle on-chain.

BIP-360: Pay-to-Merkle-Root

BIP-360 was merged into Bitcoin's BIP repository as a draft in February 2026. It proposes a new SegWit v2 output type called Pay-to-Merkle-Root (P2MR) that commits to a script tree's Merkle root without including a key-path spend. By removing the key-path spend present in Taproot, P2MR eliminates the most direct quantum attack vector on new outputs.

P2MR is a framework, not a complete solution. It defines the address structure that future post-quantum signature schemes can plug into. The actual signature algorithms (candidates include ML-DSA and SLH-DSA) have not been selected, and no activation timeline exists.

BIP-361: Quantum Migration

BIP-361, published in April 2026, proposes a three-phase migration plan for moving Bitcoin's existing supply to quantum-resistant addresses. Phase A would block new transactions from sending to quantum-vulnerable address types. Phase B, the contentious part, would eventually invalidate ECDSA and Schnorr signatures from legacy outputs, effectively freezing coins that have not migrated.

The proposal has divided the Bitcoin developer community. Proponents argue it is necessary to prevent a catastrophic quantum theft of unmigrated coins, including an estimated 1.7 million BTC in early P2PK addresses. Critics view the freeze mechanism as a violation of Bitcoin's property-rights guarantees.

When Will Quantum Computers Threaten Bitcoin?

Timeline estimates vary widely, but the research landscape shifted in 2026. A June 2026 analysis published on arXiv estimated that breaking secp256k1 would require fewer than 500,000 physical qubits: approximately 20 times fewer resources than estimated in 2019. The operation could complete in minutes once the hardware exists.

Current quantum hardware is far from this threshold. The most capable quantum processors in 2026 operate with roughly 1,000 to 1,500 physical qubits, producing at most around 100 logical qubits after error correction. The gap between current capability and the requirement for breaking ECDSA remains enormous.

Expert Consensus

• Most expert estimates place cryptographically relevant quantum computers at 2031 to 2040
• NIST recommends migrating away from ECDSA with a 2035 target deadline
• The NSA's CNSA 2.0 suite requires quantum-safe cryptography for classified systems by 2030
• Approximately 6 million BTC sit in quantum-vulnerable addresses, with roughly 2.3 million considered irreducibly at risk (coins in addresses where the public key has been exposed)

The argument for acting now, despite the distant timeline, is that cryptographic migrations in decentralized systems take years. A prompt start in 2026 might finish by 2029 to 2031, according to the arXiv analysis. Waiting until the threat is imminent leaves no margin for the slow process of consensus building, soft fork activation, and user migration.

Implications for Bitcoin Layer 2 Protocols

Lightning is not the only Layer 2 that needs to consider quantum resistance. Every Bitcoin Layer 2 protocol that relies on secp256k1 cryptography faces similar challenges, and some face additional ones.

FROST Threshold Signatures and Quantum Risk

FROST threshold signatures, used by protocols like Spark for cooperative signing between users and operators, are built on Schnorr signatures over secp256k1. A quantum computer capable of breaking individual Schnorr signatures would break FROST equally, since the underlying mathematical problem (the elliptic curve discrete logarithm) is identical.

However, Layer 2 protocols have an advantage over the base layer: they can upgrade their off-chain signing schemes without waiting for a Bitcoin soft fork. In March 2026, researchers presented Hermine at Eurocrypt 2026: the first lattice-based threshold signature scheme that provides FROST's full feature set, including partially non-interactive signing, identifiable abort, and proactive security.

For a protocol like Spark, which runs FROST signing between users and its operator set, adopting a post-quantum threshold scheme like Hermine for off-chain operations is architecturally feasible without any changes to Bitcoin L1. The on-chain anchor UTXOs would still use classical cryptography until a base-layer upgrade arrives, but the off-chain transfer layer could gain quantum resistance independently.

Layer 2 Quantum Exposure Comparison

The Performance Question for Mobile Nodes

One practical concern for Lightning's quantum transition is the impact on mobile wallet users. The PQLN research highlights that bandwidth, not computation, is the binding constraint. An ML-DSA-44 signature is 2,420 bytes compared to 64 bytes for Schnorr: a 38-fold increase per signature.

This matters most during initial graph sync, where a mobile node downloads the network's topology. At 270 MB under ML-DSA-44 gossip, this is impractical for many mobile users. The FN-DSA-512 alternative brings this down to roughly 115 MB, but that is still significantly more than today's 26 MB.

Techniques like rapid gossip sync, where a server compresses and serves graph updates, can mitigate this overhead. The PQLN authors note that their design is compatible with existing gossip compression approaches, though the compressed payloads will still be larger than their classical equivalents.

What Developers Should Do Now

The quantum threat to Lightning and other Bitcoin Layer 2 protocols is not imminent, but the harvest-now-decrypt-later risk means that sensitive data transmitted today could be exposed in the future. Developers building on the Lightning Network or other Bitcoin Layer 2s should consider several practical steps.

• Monitor the CLN 26.06 experimental quantum channel feature and test it on signet or regtest
• Follow the PQLN research and its potential integration into production Lightning implementations
• Track BIP-360 and BIP-361 progress, as on-chain quantum resistance will eventually be required for channel outputs
• Evaluate cryptographic agility in your architecture: can you swap signature schemes without redesigning your protocol?
• Consider the bandwidth implications of post-quantum gossip for mobile and constrained-resource deployments

For developers building on Spark, the Spark SDK documentation covers the current FROST-based signing architecture. Understanding how the cooperative signing model works today is the foundation for evaluating future post-quantum upgrades. The broader landscape of post-quantum cryptography's impact on Bitcoin provides additional context for planning ahead.

The Road Ahead

Core Lightning 26.06's quantum-resistant channels are a meaningful first step, but they are exactly that: a first step. The feature protects against harvest-now-decrypt-later attacks on channel establishment, which is valuable for preserving future privacy. It does not protect channel funds, which remain in quantum-vulnerable on-chain UTXOs.

The PQLN research extends protection much further across Lightning's off-chain surfaces, but it too cannot solve the on-chain problem. Full quantum resistance for Lightning requires both off-chain upgrades (which can happen through software updates) and on-chain upgrades (which require a Bitcoin soft fork).

The realistic timeline looks something like this: off-chain post-quantum protections will arrive first, through implementations like CLN 26.06 and future PQLN-based upgrades. On-chain protections depend on BIP-360 activation and a selected post-quantum signature scheme, neither of which has a timeline. The full stack will not be quantum-resistant until both layers are upgraded.

For Bitcoin Layer 2 protocols, the quantum transition is both a challenge and an opportunity. Protocols that design for cryptographic agility today will be able to adopt post-quantum schemes without architectural rewrites. Those that hardcode assumptions about key sizes, signature formats, or specific curves will face more disruptive migrations when the time comes.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.