This week's Lightning fund-theft fixes all share one shape: a node trusting a claim it never checked
Victoria Shinder2 min readRead the Bitcoin Optech newsletter for 23 October as a list of patches and it is a dull week of point releases. Read it for the shape of the bugs and it is one lesson told four times: a Lightning node lost, or could have lost, funds because it acted on a value a counterparty supplied without checking that value against something it controls.
Take the Eclair splicing fix. When splicing a simple taproot channel, a peer is allowed to provide just the amount and script of an input's previous output instead of the whole transaction. Eclair trusted those two fields. A peer could lie about either, getting Eclair to sign a splice that can never confirm — because a taproot signature commits to the real amounts and scripts of the inputs it spends — while Eclair treated that invalid splice as its latest funding state. From there the peer could publish an older commitment and claim an outgoing HTLC after Eclair's incoming one had timed out. The fix is a single sentence of principle: verify the claimed outputs against your own Bitcoin backend before signing. The trusted field becomes a checked field.
The trampoline-routing fix is the same disease in a different organ. Eclair relaxed its route-length and expiry limits when pathfinding failed, which let a payer supply blinded paths with excessive expiry deltas, break the ordering that guarantees the outgoing HTLC expires before the incoming one, and reclaim funds onchain. The fix stops relaxing the expiry limit — it stops trusting the payer's geometry. And the BOLT11 change is the purest form of all: it now requires an invoice to carry exactly one payment hash and one payment secret, because a parser that quietly picked the first while a node picked the last let an attacker point the two at different hashes and collect duplicate payouts, an exploit that was actually run against a bot. The ambiguity was the vulnerability; removing the choice removes it.
The reason this pattern recurs in Lightning specifically is structural, not careless. Lightning is a protocol for transacting with people you do not trust, over channels whose current state only the two parties hold, and every optimisation that lets a peer send less — an output's amount instead of its full transaction, a routing hint instead of a validated path — is an invitation to lie about the part you did not send. The engineering answer is not "trust less" in the abstract; it is the specific discipline these fixes encode: a value that a counterparty can choose must be checked against a value it cannot — the chain, a committed signature, a backend you run. Every one of this week's fixes is that rule applied to a place it had been skipped. The ones still skipped are next week's newsletter.