Is Lightning quantum safe?

No more and no less than the Bitcoin it is built on. Every Lightning channel is an ordinary on-chain output locked by ordinary elliptic-curve keys, so a machine that could break those keys could break a channel too. The interesting question is not whether Lightning shares the weakness, but where its keys are visible. The answer depends on the kind of channel, and for public channels it includes a place our scanner cannot look: the network's own gossip.

Lightning uses the same keys as everything else

It is easy to think of Lightning as a separate system with its own security. It is not. A channel starts with a funding transaction on the Bitcoin chain, and the money in the channel is the money in that one output. Everything that happens afterwards, every payment and every update, is a new pair of pre-signed transactions that could spend that output if either side published them.

All of those signatures use the same curve as on-chain Bitcoin. The funding keys, the node identities, the revocation keys, the keys that lock each side's balance: all secp256k1. As we explained in our first article, a large enough quantum computer running Shor's algorithm could derive a private key from its public key. That applies to a channel exactly as it applies to an address. There is no extra layer of cryptography in Lightning that a quantum attacker would have to get through first. The useful question is the one we ask about every address: which public keys are already visible, and to whom.

What a classic channel puts on-chain

The BOLT 3 specification defines the funding output in one line: a P2WSH output paying to 2 <pubkey1> <pubkey2> 2 OP_CHECKMULTISIG, where the two keys are the peers' funding keys. A P2WSH output stores only a hash of that script. Looking at the chain alone, you cannot tell a channel from any other 62-character bc1q address, and you cannot see either key.

The keys appear on-chain when the channel closes, because the closing transaction has to reveal the script to spend it. By then the funding output is spent and the keys no longer guard anything. A cooperative close pays each side to a script they chose in the shutdown message; a force close goes through a commitment transaction whose outputs are again script hashes, with the owner's balance held behind a delay before it can be swept.

Taken alone, that is a good profile: funds behind a hash for the life of the channel, keys revealed only when it is spent. If the story stopped at the chain, a classic channel would score as protected.

What a public channel tells the network

The story does not stop at the chain. For a payment to route through a channel, other nodes have to know the channel exists, and they learn that from a channel_announcement message passed around the network. BOLT 7 lists what that message carries: the two node IDs, the channel's short ID (which points at the funding output by block, transaction and output index), and two fields called bitcoin_key_1 and bitcoin_key_2. The specification says the sender must set those to the two nodes' funding keys, and that receivers should check them against the P2WSH output on-chain and ignore the announcement if they do not match.

That check is how a node proves to strangers that a real, funded channel exists. But it also means that for every public channel, both funding keys are broadcast to every node that listens, alongside the exact location of the coins they lock. Gossip is not a private exchange; it is collected, stored and published by explorers and researchers.

For exposure, that is the same situation as an address that has spent before and received again. The hash on-chain is still there, but it no longer hides anything, because the keys behind it are public. And because the output is a 2-of-2, an attacker would not need to fool either peer: deriving both private keys from the two announced public keys would be enough to sign the funding output away.

The exposure lasts as long as the channel is open and funded, which for a routing node can be a long time.

Private channels

Not every channel is announced. When a channel opens, the initiator sets a single bit, announce_channel, in the open_channel message, and only channels with that bit set exchange the signatures needed to be announced. An unannounced channel can still tell its own peer how to route through it, but BOLT 7 says that update must not be forwarded to anyone else.

In an unannounced channel, the funding keys are known to the two peers and to nobody else. That is a common setup for mobile wallets: the user has a private channel to a service provider, and the provider routes payments onwards. From the public's point of view, such a channel is a P2WSH output with nothing revealed, the protected profile from the previous section.

The obvious caveat is the peer. Your counterparty knows both funding keys, because they were exchanged when the channel opened. That is not a quantum problem in itself; your peer already has one of the two keys and could not move the funds alone. It does mean that “private” is a statement about the public network, not a guarantee that the keys exist in exactly one place.

Simple Taproot channels

In May 2026 the Lightning specification repository merged an extension called simple Taproot channels. Its design overview puts the change plainly: the 2-of-2 multisig output becomes a single P2TR key, with MuSig2 combining the two funding keys into one. The aggregated key is tweaked as in BIP-86, which the document uses whenever it wants to rule out a script path, so the funding output can only be spent by the two peers signing together.

This is the Taproot trade-off we described in our article on Taproot addresses, applied to channels. A Taproot output carries its key on-chain from the moment it is created. A cooperative channel close looks like any single-signature payment, which is better for privacy and cheaper. But the output key is visible at rest for the whole life of the channel, and a quantum attacker who derived the private key for that output key could spend it directly, without needing either peer's individual key.

For now, the extension also says these channels cannot be announced on the public network, because the gossip messages have not been updated, and that the opener must not set the announce_channel bit. So a simple Taproot channel is never exposed through gossip today; its exposure is on the chain instead. Our scanner sees that case correctly: a bc1p funding output is reported as exposed, like any Taproot output.

The moments in between

Lightning adds one thing on-chain Bitcoin does not have: timelocks that matter. If your peer broadcasts an old state, you have a window, set by to_self_delay, to publish a penalty transaction. During a force close, balances and pending payments sit behind delays before they can be swept. In each of these moments, keys are revealed in a transaction that has to confirm before a deadline.

This is the short-range attack again: deriving a key from a transaction while it waits to be confirmed, or before a timelock expires. Delays in Lightning are measured in blocks, often hours or days, which is a longer window than a normal payment sitting in the mempool. That sounds worse than it is. A short-range attack needs a machine fast enough to break a key within that window, and that is a much harder target than the long-range attack on keys sitting at rest. We do not expect it to be the first problem anyone faces, and nobody can honestly say when it would be.

What the quantum proposals say about Lightning

Nothing, so far. We checked the current text of both: neither BIP-360, which proposes a Pay-to-Merkle-Root output without an exposed key path, nor BIP-361, which proposes a timeline for retiring ECDSA and Schnorr, mentions Lightning, payment channels or pre-signed transactions.

That silence matters more for BIP-361 than for BIP-360. A channel is a bundle of pre-signed transactions that both sides hold in case they need them. A soft fork that changed which outputs may be created, or which signatures are accepted, would have to account for channels that are open when it activates. A post-quantum Lightning would have to come after a post-quantum output type for the base chain, and that work has not been specified.

What it means for you

If you use a Lightning wallet for spending, very little. A spending balance is small and moves often, which is exactly the kind of money where at-rest exposure barely matters.

If you run a routing node, or keep a meaningful amount in public channels for a long time, it is worth knowing that those funds sit behind keys the network already knows. That puts them in the same group as coins on a reused address, not in the protected group. It is not a reason to close anything today; no machine exists that could use those keys, and closing channels has its own costs. It is information to have when the protocol offers a better option.

1. Check where closes land. Whatever your node or wallet sends coins to when a channel closes becomes the next resting place for that money. If long-term savings end up there, the usual rules apply: a fresh hashed address, never reused.
2. Separate spending from saving. Channels are for money that moves. The coins you intend to hold for years belong on-chain in outputs whose keys nobody has seen, which is something you can check with the scanner.

What our scanner can and cannot see here

We should be direct about this, because Lightning is a case where our scanner can give the wrong answer.

The scanner looks only at the Bitcoin chain. It does not read Lightning gossip, and it has no way to know that a particular bc1q script address is a channel. If you paste the funding address of a public classic channel, it will see an unspent P2WSH output that has never spent and report it as protected. For on-chain purposes that is true; for exposure purposes it is not, because the two funding keys are in every node's gossip store. Treat any protected result for a public channel's funding output as wrong.

The scanner is accurate for Taproot channels, because their key is on the chain, and for your node's on-chain wallet, which is just a set of addresses. It cannot see a balance inside a channel as such, only the output that holds the whole channel, and it cannot see channels held by a custodial wallet at all.