Bitcoin Optech Newsletter #429

Silent payments for multiparty wallets

Bitcoin Optech highlights a protocol introduced by Oleksandr Kurbatov that enables silent‑payment transactions from wallets using multiparty signing schemes such as FROST and MuSig2. The design lets a coordinator collect weighted ECDH shares from each signer, then aggregate an AggDLEQ proof that satisfies BIP374. Because the proof exchange stays inside the wallet’s coordination channel, no new PSBT fields or BIP changes are required. Kurbatov notes that a paper with formal security proofs is under internal review, but the core claim—that corrupted signers and the coordinator cannot forge a proof—depends on an assumption whose hardness remains an open question.

Core Lightning denial‑of‑service vulnerability

The newsletter also details a self‑referential channel announcement bug discovered by Nishant Bansal in Core Lightning (CLN) versions 25.02 through 26.04. The software failed to enforce distinct node IDs in a channel announcement, allowing a crafted announcement to be stored on‑disk and later crash the node on every restart. Exploitation required only a funded 2‑of‑2 output and minimal on‑chain fees. The issue was responsibly disclosed, patched in CLN 26.04.1, and mirrored in BOLT 7 via requirement #1333. Operators still on vulnerable releases are urged to upgrade promptly.

Updated Bitcoin Core security policy

Antoine Poinsot announced a change to Bitcoin Core’s vulnerability handling for “easily discoverable” bugs—those that can be found with simple prompts to large language models or basic fuzzing. Instead of waiting for a major release, the project now back‑ports fixes to every maintained branch, issues point releases quickly, and publishes advisories alongside them. The three vulnerabilities referenced (Core #36665, #36667, #36669) were fixed under this new regime, causing the tagged 32.0 release to be skipped in favor of 32.1, which also brings mempool‑based fee estimation, PSBTv2 defaults, and faster block validation.

Caveats and implications

While the silent‑payment protocol appears compatible with existing standards, its security rests on an unproven assumption, meaning developers should treat it as experimental until peer‑reviewed proofs emerge. The CLN bug demonstrates how subtle protocol‑level checks can lead to systemic crashes, underscoring the importance of timely upgrades. Bitcoin Core’s policy shift reflects the growing influence of AI‑assisted code analysis and the need for rapid response to low‑severity yet widely exploitable issues.

What readers should do

For wallet developers, consider experimenting with the AggDLEQ approach in test environments but monitor forthcoming security audits before production deployment. Node operators should verify they run CLN ≥ 26.04.1 and Bitcoin Core ≥ 32.1, and apply the recommended point releases for older branches. Staying current with these updates reduces exposure to both novel protocol attacks and the expanding class of easily discoverable bugs.