This week’s newsletter links to a discussion of incremental mutation testing in Bitcoin Core and announces deployment of a new BIP process. Also included are our regular sections announcing new releases and release candidates, and describing notable changes to popular Bitcoin infrastructure projects.

News

  • ● An overview of incremental mutation testing in Bitcoin Core: Bruno Garcia posted to Delving Bitcoin about his current work on improving mutation testing in Bitcoin Core. Mutation testing is a technique that allows developers to assess the effectiveness of their tests by intentionally adding systemic bugs, called mutants, to the codebase. If a test fails, the mutant is considered “killed”, signaling that the test is able to catch the fault; otherwise, it survives, revealing a potential issue in the test.

    Mutation testing has provided significant results, leading to PRs being opened to address some reported mutants. However, the process is resource-intensive, taking more than 30 hours to complete on a subset of the codebase. This is the reason why Garcia is currently focusing on incremental mutation testing, a technique that applies mutation testing progressively, focusing only on parts of the codebase that have changed since the last analysis. While the approach is faster, it still takes too much time.

    Thus, Garcia is working on improving the efficiency of Bitcoin Core’s incremental mutation testing, following a paper by Google. The approach is based on the following principles:

    • Avoiding bad mutants, such as those syntactically different from the original program but semantically identical. This means those that will always behave in the same way regardless of the input.

    • Collecting feedback from developers to refine mutant generation, to understand where mutations tend to provide unhelpful results.

    • Report only a limited number of unkilled mutants (7, according to Google’s research), to not overwhelm developers with possibly low-informative mutants.

    Garcia tested his approach on eight different PRs, gathering feedback and suggesting changes to address mutants.

    To conclude, Garcia asked Bitcoin Core contributors to notify him on their PRs in case they wanted a mutation test run and to report feedback on the provided mutants.

  • ● BIP process updated: After more than two months of discussion on the mailing list and another round of amendments to the proposal, it became clear this week that BIP3 had achieved rough consensus. With BIP3’s deployment on Wednesday, it replaced BIP2 as the guideline for the BIP process. While large parts of the BIP process remain unchanged, BIP3 introduces several simplifications and improvements.

    Among other changes, the comment system is dropped, the count of BIP statuses is reduced from nine (Draft, Proposed, Active, Final, Rejected, Deferred, Withdrawn, Replaced, and Obsolete) to four (Draft, Complete, Deployed, and Closed), the preamble headers are updated, the Standards Track type is replaced with the Specification type, and some judgment calls previously required from BIP Editors are reassigned to BIP authors or the readers.

    An overview of all changes can be found in BIP3.

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 30.2 is a maintenance release that fixes a bug where the entire wallets directory could be accidentally deleted when migrating an unnamed legacy wallet (see Newsletter #387). It includes a few other improvements and fixes; see the release notes for all details.

  • ● BTCPay Server 2.3.3 is a minor release of this self-hosted payment solution that introduces cold wallet transaction support via the Greenfield API (see below), removes CoinGecko-based exchange rate sources, and includes several bug fixes.

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 #33819 introduces a new getCoinbaseTx() method on the Mining interface (see Newsletter #310) to return a struct containing all the fields clients need to construct a coinbase transaction. The existing getCoinbaseTx() method, which instead returned a serialized dummy transaction that clients had to parse and manipulate, is renamed to getCoinbaseRawTx() and is deprecated alongside getCoinbaseCommitment(), and getWitnessCommitmentIndex().

  • ● Bitcoin Core #29415 adds a new privatebroadcast boolean option to broadcast transactions through short-lived Tor or I2P connections, or through the Tor proxy to IPv4/IPv6 peers, when using the sendrawtransaction RPC. This approach protects the privacy of the transaction originator by concealing their IP address and by using separate connections for each transaction to prevent linkability.

  • ● Core Lightning #8830 adds a getsecret command to the hsmtool utility (see Newsletter #73) that replaces the existing getsecretcodex command with additional support for recovering nodes created after the changes introduced in v25.12 (see Newsletter #383). The new command outputs the BIP39 mnemonic seed phrase for a given hsm_secret file for new nodes, and retains the functionality of outputting Codex32 strings for legacy nodes. The recover plugin is updated to accept mnemonics.

  • ● Eclair #3233 starts using the configured default feerates when Bitcoin Core fails to estimate fees on testnet3 or testnet4 due to insufficient block data. The default feerates are updated to better match current values.

  • ● Eclair #3237 reworks the channel lifecycle events to be compatible with splicing and consistent with zero-conf by adding the following: channel-confirmed, which signals that the funding transaction or splice has been confirmed, and channel-ready, which signals that the channel is ready for payments. The channel-opened event is removed.

  • ● LDK #4232 adds support for the experimental accountable signal, which replaces HTLC endorsement, as proposed in BLIPs #67 and BOLTs #1280. LDK now sets zero-value accountable signals on its own payments and on forwards with no signal, and copies the incoming accountable value to outgoing forwards when present. This follows similar changes in Eclair and LND (see Newsletter #387).

  • ● LND #10296 adds an inputs field to the EstimateFee RPC command request, allowing users to get a fee estimate for a transaction using specific inputs instead of letting the wallet select them automatically.

  • ● BTCPay Server #7068 adds support for cold wallet transactions via the Greenfield API, allowing users to generate unsigned PSBTs and broadcast externally signed transactions through a new endpoint. This feature provides greater security in automated environments and enables setups that meet higher regulatory compliance requirements.

  • ● BIPs #1982 adds BIP433 to specify the Pay-to-Anchor (P2A) standard output type and makes spending of this output type standard.

Want more?

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