This week’s newsletter includes our regular sections summarizing a Bitcoin Core PR Review Club meeting and describing notable changes to popular Bitcoin infrastructure projects.

News

No significant news this week was found in any of our sources.

Bitcoin Core PR Review Club

In this monthly section, we summarize a recent Bitcoin Core PR Review Club meeting.

Testing Bitcoin Core 31.0 Release Candidates was a review club meeting that did not review a particular PR, but rather was a group testing effort.

Before each major Bitcoin Core release, extensive testing by the community is considered essential. For this reason, a volunteer writes a testing guide for a release candidate so that as many people as possible can productively test without having to independently ascertain what’s new or changed in the release, and reinvent the various setup steps to test these features or changes.

Testing can be difficult because when one encounters unexpected behavior, it’s often unclear if it’s due to an actual bug or if the tester is making a mistake. It wastes developers’ time to report bugs to them that aren’t real bugs. To mitigate these problems and promote testing efforts, a Review Club meeting is held for a particular release candidate.

The 31.0 release candidate testing guide was written by svanstaa (see Podcast #397), who also hosted the review club meeting.

Attendees were also encouraged to get testing ideas by reading the 31.0 release notes.

The testing guide covers cluster mempool including new RPCs and cluster limits (see Newsletter #382), private broadcast (see Newsletter #388), an updated getblock RPC with a new coinbase_tx field (see Newsletter #394), a new txospenderindex which tracks which transaction spends each output (see Newsletter #394), an increased default -dbcache size (see Newsletter #396), embedded ASMap data (see Newsletter #394), and a new REST API blockpart endpoint (see Newsletter #386).

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 #33908 adds btck_check_block_context_free to the libbitcoinkernel C API (see Newsletter #380) for validating candidate blocks with context-free checks: block size/weight limits, coinbase rules, and per-transaction checks that do not depend on chainstate, the block index, or the UTXO set. Callers can optionally enable proof-of-work verification and merkle-root verification in this endpoint.

  • Eclair #3283 adds a fee field (in msats) to the full-format responses of the findroute, findroutetonode, and findroutebetweennodes endpoints used for pathfinding. This field provides the route’s total forwarding fee, eliminating the need for callers to compute it manually.

  • LDK #4529 enables operators to set different limits for announced and unannounced channels when configuring the total value of inbound HTLCs in flight, as a percentage of channel capacity. The defaults are now 25% for announced channels and 100% for unannounced channels.

  • LDK #4494 updates its internal RBF logic to ensure compliance with BIP125’s replacement rules at low feerates. Instead of only applying the 25/24 feerate multiplier specified in BOLT2, LDK now uses whichever is larger: that multiplier or an additional 25 sat/kwu. A related specification clarification is being discussed in BOLTs #1327.

  • LND #10666 adds a DeleteForwardingHistory RPC and an lncli deletefwdhistory command, enabling operators to selectively delete forwarding events older than a chosen cutoff timestamp. A minimum age guard of one hour prevents the accidental removal of recent data. This feature enables routing nodes to delete historical forwarding records without resetting the database or taking the node offline.

  • BIPs #2099 publishes BIP393, which specifies an optional annotation syntax for output script descriptors, enabling wallets to store recovery hints, such as a birthday height to speed up wallet scanning (including for silent payment scanning). See Newsletter #394 for initial coverage of this BIP with additional details.

  • BIPs #2118 publishes BIP440 and BIP441 as Draft BIPs in the Great Script Restoration (or Grand Script Renaissance) series (see Newsletter #399). BIP440 proposes the Varops Budget for Script Runtime Constraint (see Newsletter #374); BIP441 describes a new tapscript version that restores opcodes disabled in 2010 such as OP_CAT (see Newsletter #374) and limits script evaluation costs per the varops budget introduced in BIP440.

  • BIPs #2134 updates BIP352 (silent payments) to warn wallet developers not to let policy filtering, such as for dust, affect whether scanning continues after a match is found. Treating a filtered-out output as if there were no match can cause the wallet to prematurely stop scanning and miss later outputs from the same sender.

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 April 14. The discussion is also recorded and will be available from our podcasts page.