Bitcoin Optech Newsletter #429

Bitcoin Optech Newsletter #429 – Highlights

This edition brings three major updates for developers and operators: a novel silent‑payment protocol that lets multiparty wallets create BIP‑374‑compatible transactions, a responsible‑disclosure fix for a denial‑of‑service flaw in older Core Lightning releases, and Bitcoin Core’s refreshed security policy for quickly patching easily discoverable bugs. The newsletter also includes a curated Q&A from Bitcoin Stack Exchange, the latest release notes for core infrastructure software, and a roundup of notable code changes.

Silent Payments from Multiparty Wallets

Oleksandr Kurbatov outlined a protocol that extends BIP‑352 silent payments to inputs contributed by multiple signers. The approach works with existing multiparty signing schemes such as FROST and MuSig2 and requires no new PSBT fields. A coordinator distributes a session context (signer set, protocol coefficients, tweak, transaction data, and a session ID). In the first round each signer generates two nonces and an AggDLEQ proof component, which the coordinator aggregates into a combined ECDH share and challenge. The second round sees each signer produce a response to that challenge; the coordinator then assembles a single aggregated proof compatible with BIP‑374.

Key points for implementers:

• No changes to BIP‑352, BIP‑374, BIP‑375, or the underlying MuSig2/FROST protocols are required.
• Communication stays within the wallet’s internal coordinator channel; external nodes see only a standard silent‑payment transaction.
• Security proofs are under internal review, and the protocol’s hardness relies on an assumption that remains an open research question.

Developers interested in experimenting should follow the two‑round flow and verify the aggregated DLEQ proof against the BIP‑374 verification routine.

Core Lightning Self‑Referential Channel Announcement DoS

Nishant Bansal disclosed a vulnerability affecting Core Lightning (CLN) versions 25.02 – 26.04. The bug arose because CLN did not enforce that the two node IDs in a channel announcement differ. An attacker could craft an announcement where both endpoints are the same node, causing the gossip store to write a malformed entry. When the node later loaded this entry, the in‑memory graph attempted to add the same node twice, triggering a duplicate‑node assertion and crashing the process. The malformed announcement persisted on disk, causing repeated crashes on each restart until manually removed.

Impact and exploitation

• The attacker only needed to fund a 2‑of‑2 output they controlled and sign the announcement with a fresh node key, limiting the cost to on‑chain transaction fees.
• Older CLN releases accepted and relayed such announcements without crashing, potentially spreading the payload to vulnerable nodes.

Mitigation

• The issue was responsibly disclosed in April and fixed in CLN 26.04.1. The fix rejects any announcement where `nodeid1` is not strictly less than `nodeid2`.
• BOLT 7 was updated (BOLTs #1333) to require the same ordering on the receiver side.
• Operators on affected versions should upgrade immediately.

Bitcoin Core Security Policy Update

Antoine Poinsot announced a policy change for vulnerabilities classified as easily discoverable—for example, bugs that can be found by prompting a large‑language model. The new workflow:

1. Backport fixes to every maintained release line.
2. Cut point releases as soon as the fix lands.
3. Publish an advisory alongside the release.

This shift responds to a rise in low‑effort bug reports that could otherwise be silently incorporated into later releases. The three recent security fixes (#36665, #36667, #36669) were handled under the new policy and shipped in Bitcoin Core 32.1, as well as the maintenance releases 31.2, 30.4, and 29.5.

Quick recap of the three fixes

• #36665 – Stops a memory‑exhaustion attack that leveraged TCP urgent data on Windows/macOS/BSD sockets.
• #36667 – Adds a send‑buffer timeout to disconnect peers that exceed their buffer for more than 20 minutes, preventing unbounded memory growth.
• #36669 – Expands undo‑file offsets to 64 bits, eliminating overflow‑induced corruption on reorgs for large undo files.

Operators should upgrade to the latest releases to benefit from these patches and the faster point‑release cadence.

Selected Q&A from Bitcoin Stack Exchange

• Why does Bitcoin use both a transaction ID and a witness transaction ID?

Pieter Wuille explains that SegWit moved signatures into the witness, which the traditional `txid` omits. The `wtxid` includes the witness, allowing nodes to reject tampered blocks without re‑processing every variant.

• How to sign a MuSig with Bitcoin Core?

Ava Chow outlines the two‑round MuSig2 flow: the first PSBT pass adds each signer’s public nonce, the second pass (after all nonces are present) adds partial signatures, and `finalizepsbt` produces the fully signed transaction.

• What changed in P2P protocol version 70017?

Ava Chow notes that BIP‑434 introduced a new feature‑negotiation message during the version handshake, replacing the older practice of bumping the protocol version for each new feature.

Releases & Release Candidates

• Bitcoin Core 32.1 – Major release with the three security fixes, default PSBT v2, watch‑only wallet exports, and faster block validation. Older 29.x series are end‑of‑life.
• Bitcoin Core 31.2, 30.4, 29.5 – Maintenance releases back‑porting the same security fixes and adding minor improvements (e.g., BIP‑323 warning changes, queue caps, DNS seed removals).
• Eclair 0.14.6, LND v0.21.5‑beta / v0.20.6‑beta – Security and maintenance updates addressing splicing force‑close, commitment feerate bugs, TLV memory allocation, and SQL deadlocks.

Notable Code Changes

• Bitcoin Core #36665, #36667, #36669 – Memory‑exhaustion, send‑buffer timeout, and undo‑file overflow fixes.
• BIPs #2130 (draft BIP‑139) – Introduces a JSON wallet‑metadata export format for accounts, descriptors, labels, and PSBTs, facilitating wallet migration.

---

Practical takeaways

1. Upgrade Core Lightning to 26.04.1 or later and apply the latest Bitcoin Core release to stay protected against the disclosed DoS and memory‑related bugs.
2. Experiment with the silent‑payment multiparty protocol in a testnet environment, paying close attention to the AggDLEQ proof aggregation steps.
3. Monitor the Bitcoin‑Core mailing list for future easily‑discoverable‑vulnerability advisories and plan for rapid point‑release deployments.

Staying current with these developments helps maintain a resilient Bitcoin ecosystem and prepares developers for the next wave of protocol enhancements.