This week’s newsletter shares an update on differential fuzzing of Bitcoin and LN implementations and links to a new paper about garbled locks for accountable computing contracts. Also included are our regular sections summarizing popular questions and answers from the Bitcoin Stack Exchange, announcing new releases and release candidates, and describing notable changes to popular Bitcoin infrastructure software.

News

• ● Update on differential fuzzing of Bitcoin and LN implementations: Bruno Garcia posted to Delving Bitcoin to describe recent progress and accomplishments of bitcoinfuzz, a library and related data for fuzz testing Bitcoin-based software and libraries. Accomplishments include the discovery of “over 35 bugs in projects such as btcd, rust-bitcoin, rust-miniscript, Embit, Bitcoin Core, Core Lightning, [and] LND.” Discovered discrepancies between LN implementations has not only revealed bugs but has also driven clarifications to the LN specification. Developers of Bitcoin projects are encouraged to investigate making their software a supported target for bitcoinfuzz.

• ● Garbled locks for accountable computing contracts: Liam Eagen posted to the Bitcoin-Dev mailing list about a paper he’s written about a new mechanism for creating accountable computing contracts but based on garbled circuits. This is similar (but distinct) from other recent independent work on using garbled circuits for BitVM (see Newsletter #359). Eagen’s post claims “the first (in his opinion) practical garbled lock whose fraud proof is a single signature, which represent over a 550x reduction of onchain data compared to BitVM2.” As of this writing, his post has not received any public replies.

Selected Q&A from Bitcoin Stack Exchange

Bitcoin Stack Exchange is one of the first places Optech contributors look for answers to their questions—or when we have a few spare moments to help curious or confused users. In this monthly feature, we highlight some of the top-voted questions and answers posted since our last update.

• ● Is it possible to recover a private key from an aggregate public key under strong assumptions? Pieter Wuille explains current and hypothetical security assumptions around MuSig2 scriptless multisignatures.

• ● Are all taproot addresses vulnerable to quantum computing? Hugo Nguyen and Murch point out that even taproot outputs constructed to be spent only using script paths are quantum vulnerable. Murch goes on to note “Interestingly, the party that generated the output script would be able to show that the internal key was a NUMS point and thus prove that a Quantum Decryption has occurred.”

• ● Why cant we set the chainstate obfuscation key? Ava Chow highlights that the key that obfuscates on-disk contents of the blocksdir (see Newsletter #339) is not the same key that obfuscates the chainstate contents (see Bitcoin Core #6650).

• ● Is it possible to revoke a spending branch after a block height? Antoine Poinsot points to a previous answer confirming that expiring spending conditions, or “inverse timelocks”, are not possible and perhaps not even desirable.

• ● Configure Bitcoin Core to use onion nodes in addition to IPv4 and IPv6 nodes? Pieter Wuille clarifies that setting the onion configuration option only applies to outbound peer connections. He goes on to outline how to configure Tor and bitcoind for inbound connections.

Releases and release candidates

New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates.

• ● Bitcoin Core 29.1rc2 is a release candidate for a maintenance version of the predominant full node software.

• ● Core Lightning v25.09rc4 is a release candidate for a new major version of this popular LN node implementation.

Notable code and documentation changes

Notable recent changes in Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, Lightning BLIPs, Bitcoin Inquisition, and BINANAs.

• ● Bitcoin Core #31802 enables inter-process communication (IPC) by default (ENABLE_IPC), adding the bitcoin-node and bitcoin-gui multiprocess binaries to the release builds on all systems except Windows. This allows an external Stratum v2 mining service that creates, manages and submits block templates to experiment with the multiprocess layout without custom builds. For additional context on the multiprocess project and the bitcoin-node binary, see Newsletters #99, #147, #320, #323.

• ● LDK #3979 adds splice-out support, enabling an LDK node to both initiate a splice-out transaction, and accept requests from a counterparty. This completes LDK’s splicing implementation, as LDK #3736 already added splice-in support. This PR adds a SpliceContribution enum that covers both in and out scenarios and ensures that the output values of a splice-out transaction don’t exceed the user’s channel balance after accounting for fees and reserve requirements.

• ● LND #10102 adds a gossip.ban-threshold option (100 is the default, 0 disables it) that allows users to configure the score threshold at which a peer is banned for sending invalid gossip messages. The peer banning system was previously introduced and covered in Newsletter #319. This PR also resolves an issue where unnecessary node and channel announcement messages were sent in response to a backlog gossip query request.

• ● Rust Bitcoin #4907 introduces script tagging by adding a new generic tag parameter T to Script and ScriptBuf, and defines the type aliases ScriptPubKey, ScriptSig, RedeemScript, WitnessScript, and TapScript which are backed by a sealed Tag trait for compile-time role safety.

Want more?

For more discussion about the topics mentioned in this newsletter, join us for the weekly Bitcoin Optech Recap on Riverside.fm at 16:30 UTC on September 2. The discussion is also recorded and will be available from our podcasts page.