Core Lightning could mistake a cheating close for a cooperative one
Serguey Asael Shinder2 min readBitcoin Optech's newsletter of 25 September explains a fix in Core Lightning (CLN), one of the main Lightning Network node implementations, that closes a way for a channel peer to cheat without being punished.
Lightning channels are updated by exchanging new commitment transactions; old ones are revoked. If a peer broadcasts a revoked commitment, the other side can normally claim a penalty that takes the cheater's funds. According to Optech, CLN could instead treat a force-close as a cooperative close if all of its outputs paid to shutdown scripts it already knew. A peer that had not committed to an upfront shutdown script when opening the channel could send a shutdown message naming the output script of an old revoked commitment, abandon the cooperative close, and then broadcast that commitment without being penalised. CLN now identifies commitment transactions by their locktime and sequence encoding before considering whether their outputs look like a mutual close. The same change restarts on-chain monitoring after certain reorganisations and fixes several crashes.
The fix shipped in v26.06.7 on 28 August under a two-week embargo; its source was published on 11 September. The project's release notes add an operational warning: between 28 August and 1 September, Docker images tagged v26.06.7 and latest reported the new version on startup but did not contain the fixes, because CI published them from a placeholder tag. Anyone who pulled then should check the image digest against the table in the release notes and re-pull. CLN 26.06.8, released on 22 September with further security fixes, is the version the project strongly recommends; its source is available immediately, though a few tests are temporarily withheld.
What it means
Lightning's security model depends on the penalty for broadcasting old states; if a node can be tricked into not recognising a revoked commitment, the deterrent disappears for that channel. The condition here was narrow - a peer without an upfront shutdown script, and a node running an older build - so a vulnerable version does not mean every channel was exposed.
The Docker episode is the broader lesson. A version string is not proof of the code inside an image; the digest is. For node operators, pinning images by digest rather than by tag avoids exactly this failure.