LND's channel-close flaw can drain a full balance: the fix version confusion is the real danger

The Lightning Network has a dirty secret: its channel-closing logic has been trusting one Bitcoin confirmation for too long. That trust just turned into a full-balance vulnerability in LND, the most popular node implementation. And here's the part that should make you angry: the initial disclosure told operators the wrong version to upgrade to.

One block is all it takes

What you need to know: a malicious channel peer can now, under the right conditions, drain every satoshi in a channel. The attacker doesn't need 51% of hashrate. They don't need to hack your node. They need one thing: a one-block Bitcoin reorganization.

Here's how it works. The attacker goes through a cooperative close with you. That's the normal, friendly way to close a channel. The closing transaction lands on-chain and gets its first confirmation. LND, in versions before the real fix, considers the channel resolved at that moment. It forgets the state it needs to defend itself.

Then the reorg happens. That one confirmation disappears. The attacker, who never stopped being malicious, publishes an old revoked commitment transaction. That's an outdated balance state that should trigger an automatic penalty. But your node already deleted the data it needed to broadcast that penalty. So the revoked state stands, and your balance goes to the attacker.

The maximum loss is the channel's entire balance. Not a portion. Not a percentage. All of it. That's what the reproduced scenario shows.

Here's the saving grace: nobody is known to have been hit. Bastien Teinturier, who published the disclosure, said no affected users were known. That's good news. But it's luck, not security.

Wait, is this really that bad?

Let's steelman the skeptics. This attack isn't trivial. You need a malicious peer to participate in a cooperative close. You need a one-block reorg to actually happen. And you need that same peer to have kept an old revoked commitment transaction around. That's a lot of moving pieces.

Bitcoin reorgs of one block aren't common, but they're not imaginary. They happen. Miners get lucky, or unlucky, and a block gets orphaned. The attacker doesn't need to control the reorg. They just need to be ready when one occurs. And they can wait. Channels don't expire.

Some will also say this only affects LND, not other Lightning implementations. That's true. The disclosure and fix are specific to LND. But LND is the implementation that runs a huge share of the network's nodes and channels. When the most popular implementation has a full-balance bug, the whole network's reputation takes the hit.

The real outrage here isn't the bug itself. Software has bugs. The real outrage is the upgrade confusion.

The public disclosure pointed operators to version 0.20.0 as the fix cutoff. But the upstream repository history tells a different story. Pull request #10331 merged into master on Jan. 16, 2026. A backport to the 0.20.x branch was reverted. The release notes for 0.21.0 associate the reorganization-safe close logic with that release line. The official fix is in 0.21.0, not 0.20.0.

So if you're running 0.20.0 or anything below 0.21.0, you should treat your node as lacking the official fix. Unless you independently patched it. How many node operators know that today? Not enough.

Upgrade today. Then ask why the version numbers didn't match.

Here's my verdict: this is a preventable disaster that got saved by timing, and the version mismatch is unacceptable.

Let's start with the practical part. LND's own security policy recommends the latest minor release of the newest major line. As of Aug. 25, that's v0.21.2-beta, released Aug. 13. If you're operating a Lightning node, you should be on that version. Not 0.20.x. Not 0.21.0-beta. The latest one.

The fix itself is solid. LND now retains channel close state while waiting for multiple confirmations. It reacts to reorganization notifications instead of treating the first confirmation as final. That's the right behavior. Bitcoin's security model has always said wait for more confirmations. LND just learned that lesson the hard way.

But here's the thing: a one-block reorg shouldn't be able to drain a channel even if your node is running old software. The penalty mechanism exists for exactly this reason. When a peer publishes a revoked commitment, the protocol is supposed to punish them. That's the entire game theory holding Lightning together. The flaw here isn't just a coding error. It's a breach of that game theory assumption.

So yes, upgrade. But also think about what this means for the network. Lightning keeps getting hit with these channel-wipeout scenarios. Each time, the answer is "upgrade and move on." That's fine for today. But trust in the network depends on these bugs staying theoretical. This one stayed theoretical. The next one might not.

What's a channel balance worth if a single orphaned block can take it? That's the question every node operator should be asking while they upgrade to 0.21.2-beta today.

The number that matters today: 0.21.0. Everything below that's exposed to a full-channel wipeout scenario. Don't wait for the next disclosure to check your version.