Bitcoin Optech Newsletter #427

Bitcoin Optech Newsletter #427 – Highlights

1. Critical DoS vulnerabilities patched in Eclair

Two denial‑of‑service bugs were disclosed for Eclair v0.14.0 and earlier, both resolved in v0.14.1 (July 2026). The first is a race condition in the duplicate `temporarychannelid` check that lets an attacker flood a node with identical `openchannel` messages, creating orphaned channel states and exhausting memory (≈1 MB/s). The second bypasses the pending‑channel limiter by reusing a final `channelid` as a new temporary ID, allowing an attacker to open an unbounded number of pending channels. Each pending channel copies the peer’s feature set; by setting a high‑order unknown feature bit the copy inflates to ~65 kB, draining a 4 GB node in under an hour. Mobile wallets that rely on ACINQ‑patched LSPs (e.g., Phoenix) are unaffected. Users should upgrade to Eclair v0.14.1 immediately.

2. LN‑GAP: Running complex contracts inside Lightning channels

Adam Gibson introduced LN‑GAP, a protocol for executing multi‑round, two‑party contracts off‑chain while guaranteeing on‑chain dispute resolution in a constant number of transactions. The proposal is demonstrated with a chess‑game implementation where the winner claims the full pot. Key ideas:

• A venue (a committee of members) attests only to the timeliness of a published move, not its content, using one‑bit signatures verified with `OP_CHECKSIGADD`.
• Dispute resolution follows a three‑step on‑chain flow: (1) a claim that no event was published, (2) a rebuttal with the move and venue attestation, (3) a disproval if the rebuttal is non‑compliant.
• Fees for venue members are paid atomically via adaptor signatures, avoiding the need for threshold signatures like FROST.
• Security relies on an honest‑majority assumption; collusion of > 50 % of venue members could enable theft.

Potential applications extend beyond games to proof‑of‑storage bonds and off‑chain dispute mechanisms similar to BitVMX‑style verifiers.

3. Release candidates and notable bug fixes

Bitcoin Core

• v32.0‑rc4 is now available. Testers should follow the provided testing guide to help harden the upcoming major release.

Lightning implementations

• Eclair

- PRs #3396‑#3400 tighten splice handling, preventing peers from blocking HTLC enforcement via malicious locktimes, relative timelocks, or low feerates. - PRs #3399‑#3395 address on‑the‑fly funding bugs that could cause loss of incoming HTLCs or leave malformed onion packets unresolved. - PR #3401 fixes a disconnection edge case where a forwarding node could lose funds after an instruction is incorrectly discarded.

• LDK

- #5080 ensures HTLCs are still processed during cooperative channel shutdowns. - #5087 patches a privacy leak where dummy hops accepted message‑content TLV records, allowing an observer to infer hop boundaries.

• LND

- #11068 adds a missing check for auxiliary HTLC signatures in experimental Taproot overlay channels, preventing asset‑HTLC loss on force‑close.

• Rust‑Bitcoin

- #6956 introduces a `ScriptCode` type to correctly represent the script portion used in legacy and SegWit‑v0 signature hashing, aligning the library with BIP‑143 semantics.

4. Practical steps for operators

1. Upgrade immediately to Eclair v0.14.1 and verify that your node no longer accepts duplicate `temporarychannelid` messages.
2. Test the Bitcoin Core rc4 in a staging environment; focus on consensus‑critical changes and new RPC behaviours.
3. Review recent PRs in your Lightning implementation of choice, especially those related to splice safety, HTLC handling during shutdown, and privacy of blinded paths.
4. Consider LN‑GAP if your use‑case involves complex off‑chain contracts. Evaluate the venue composition and ensure an honest‑majority model is realistic for your deployment.
5. Monitor release notes for upcoming versions of LDK, LND, and Rust‑Bitcoin to stay aligned with security‑focused improvements.

--- Stay secure, keep testing, and enjoy building on a resilient Bitcoin ecosystem.