Bitcoin Optech #427: Eclair DoS disclosures, an offchain-contracts proposal, Core 32.0rc4

Victoria Shinder17 October 2026, 08:542 min read

Bitcoin Optech's Newsletter #427, published 16 October 2026, covers two disclosed denial-of-service vulnerabilities in the Lightning implementation Eclair, a proposal for running complex contracts inside Lightning channels, and the regular lists of releases and notable changes. It is a weekly digest, so the items below are pointers to the underlying disclosures and discussions.

Two Eclair DoS vulnerabilities, fixed in v0.14.1. Erick Cestari posted the responsible disclosure to Delving Bitcoin; both flaws were fixed in Eclair #3324 and released in v0.14.1 in July, so anyone on an older version should upgrade. The first, found by Matt Morehouse with his smite fuzzer, is a race condition in the duplicate temporary_channel_id check: Eclair checked the ID before recording the new channel, so rapid identical open_channel messages could get two past the check, leaving an unreachable channel state holding about 25 kB until the peer disconnected — about 1 MB per second leaked under repetition. The second, found by Cestari, bypassed Eclair's limit on unconfirmed pending channels by reusing a channel's final channel_id as the next temporary_channel_id; with a single high-position unknown feature bit inflating each stored copy to about 65 kB, one connection exhausted a 4 GB node in about 48 minutes, and because pending channels are written to the database the node crashed again on each restart. Morehouse noted that mobile wallets using an Eclair node as their LSP, such as Phoenix, are unaffected because ACINQ patched its nodes months ago.

LN-GAP: offchain contracts in channels. Adam Gibson posted to the Bitcoin-Dev list a proposal to run complex, multi-round, two-party contracts inside a Lightning channel while settling disputes onchain in a constant number of transactions, with a chess game as the worked example (a repository and paper are available). Because Lightning cannot enforce rules when a counterparty stalls, LN-GAP adds a venue — a committee that only attests whether a signed message was published before a deadline, never holding funds — using per-member one-bit signatures checked with OP_CHECKSIGADD and fees paid over channels with adaptors. It relies on an honest-majority assumption: if more than half the venue colludes with a party, funds can be stolen. (The newsletter is the pointer; this item is discussed further on the analysis desk.)

Releases and notable changes. Bitcoin Core 32.0rc4 is a release candidate for the next major version. The newsletter also lists fixes across the Lightning stack, including several Eclair PRs hardening onchain HTLC enforcement during splicing (#3396, #3397, #3400) and on-the-fly funding (#3399, #3394), an LDK fix for HTLCs during cooperative close (#5080) and an LDK onion-message privacy fix (#5087), an LND check for auxiliary HTLC signatures on Taproot Assets channels (#11068), a Rust Bitcoin ScriptCode type for BIP143 signature hashing (#6956), and a BDK reorg fix (#2319).

Source: Bitcoin Optech, "Newsletter #427" — https://bitcoinops.org/en/newsletters/2026/10/16