What happened
On 13 August 2026 Bastien Teinturier of ACINQ posted a disclosure to Delving Bitcoin about LND, the Lightning implementation maintained by Lightning Labs. In the affected versions, "lnd would forget channels that were collaboratively closed immediately after their first on-chain confirmation, without waiting for more blocks to protect against reorgs. If a 1-block reorg happened, an attacker could then publish any revoked state for that channel and lnd would not publish penalty-transactions, resulting in a loss of funds up to the entire channel amount." He found it in February 2025 while testing cooperative closes between Eclair and LND, and the post includes the regtest steps to reproduce it.
What it changes
The mechanism is worth following, because it is the same one every Lightning channel rests on. Both sides of a channel hold signed commitment transactions for every past balance, and each time the balance moves the old one is revoked. Revoked does not mean deleted: your counterparty still has a valid transaction paying themselves an old, better balance. What stops them broadcasting it is that you are watching, and a revoked state gives you the key material to take the whole channel as a penalty.
Watching is the entire defence, so a node that stops watching has no defence. LND stopped after one confirmation on a cooperative close. A chain reorganisation of a single block undoes that confirmation, and the peer who agreed to the close is free to broadcast a revoked state into the rebuilt chain against a node that is no longer looking.
LND now waits. Its release notes record that channel closes require "between 3 and 6 confirmations, scaled linearly with channel capacity up to the maximum non-wumbo channel size (~0.168 BTC), with wumbo channels always requiring 6 confirmations". Teinturier's own summary of the lesson is that implementations "should not let node operators use values lower than 6".
What it does not change
Nobody is known to have lost anything: the disclosure says "nobody was impacted as far as we know", and the attack needs a peer who both agreed to a cooperative close and can get a reorg to land.
The version information is the part to check before relaxing. The disclosure states the fix
shipped in v0.20.0 in February 2026. LND's own release notes place the change,
pull request 10331, under 0.21.0,
which was released on 5 June 2026, and no 0.20.x release note mentions it. The code says the
same thing: at the v0.20.3-beta tag, released on 13 August 2026, the same day as the
disclosure,
the chain watcher
does not contain the word reorg at all, while
the 0.21.0 version of the same file
contains it sixteen times.
CryptoSlate reported on 26 August
that a backport to the 0.20 branch was reverted. The 0.20 line is still maintained, so a
node reading "fixed in 0.20.0" and staying put is not covered by that sentence.
Waiting for confirmations reduces exposure rather than removing it. Six blocks is a convention about how deep a reorg is likely to go, not a guarantee about how deep one can go, and the same reasoning applies to any confirmation policy anywhere.
Context
This is the second bound LND has put on what a peer can do to it this month, after a cap on how much channel graph data one peer could make a node accumulate. Both are the same shape of fix: a peer is not an adversary you can reason about, so the node's own behaviour has to hold regardless of what the peer does.
The reusable part is not about Lightning. A disclosure is only as useful as the version number in it, and that number is the one line a reader acts on without checking. Reading the release notes for the version you actually run costs a minute.