This week’s newsletter summarizes discussion about a new push for a consensus cleanup soft fork and announces a plan to choose additional BIP editors by the end of the week. Also included are our regular sections announcing new releases and describing changes to popular Bitcoin infrastructure software.

News

  • ● Revisiting consensus cleanup: Antoine Poinsot posted to Delving Bitcoin about revisiting Matt Corallo’s consensus cleanup proposal from 2019 (see Newsletter #36). He starts by attempting to quantify the worst case of several problems the proposal could fix, including: the ability to create a block that can take more than 3 minutes to verify on a modern laptop and 90 minutes to verify on a Raspberry Pi 4; the ability for miners to steal subsidy and make LN insecure using the time warp attack with about a month of preparation; the ability to trick light clients into accepting fake transactions (CVE-2017-12842) and confuse full nodes into rejecting valid blocks (see Newsletter #37).

    In addition to the above concerns from Corallo’s original consensus cleanup, Poinsot suggests addressing the remaining duplicate transactions problem that will begin affecting full nodes at block 1,983,702 (and already affects testnet nodes).

    All of the problems above have technically simple solutions that can be deployed in a soft fork. The previously proposed solution for slow-verification blocks was slightly controversial given that it could in theory have made invalid some scripts people might have theoretically used with presigned transactions, potentially violating the confiscation avoidance development policy (see Newsletter #37). We’re unaware of any actual use of such a script, either in the 10 years Bitcoin existed before the original consensus cleanup proposal or the 5 years since, although some types of use would be impossible to detect until a presigned transaction was broadcast.

    To address the concern, Poinsot proposed that the updated consensus rules only apply to transaction outputs created after a particular block height. Any outputs created earlier than that height would still be spendable under the old rules.

  • ● Choosing new BIP editors: Mark “Murch” Erhardt continued the thread about adding new BIP editors by proposing everyone express “their arguments for and against any candidates in this thread until Friday end-of-day (April 5th). If any candidates find broad support, those candidates could be added as new editors to the repository on the following Monday (April 8th).”

    Discussion was ongoing at the time of writing and we will do our best to report on the results in next week’s newsletter.

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 26.1 is a maintenance release of the network’s predominant full node implementation. Its release notes describe several bug fixes.

  • ● Bitcoin Core 27.0rc1 is a release candidate for the next major version of the network’s predominant full node implementation. Testers are encouraged to review the list of suggested testing topics.

  • ● HWI 3.0.0-rc1 is a release candidate for the next version of this package providing a common interface to multiple different hardware signing devices.

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, Bitcoin Inquisition, and BINANAs.

Note: the commits to Bitcoin Core mentioned below apply to its master development branch and so those changes will likely not be released until about six months after the release of the upcoming version 27.

  • ● Bitcoin Core #27307 begins tracking the txid of transactions in the mempool that conflict with a transaction belonging to Bitcoin Core’s built-in wallet. This includes transactions in the mempool that conflict with an ancestor of a wallet transaction. If a conflicting transaction gets confirmed, the wallet transaction cannot be included on that blockchain, so it’s very useful to know about conflicts. Conflicting mempool transactions are now shown in a new mempoolconflicts field when calling gettransaction on the wallet transaction. Inputs to a mempool-conflicted transaction may be respent without manually abandoning the mempool-conflicted transaction and are counted towards the wallet’s balance.

  • ● Bitcoin Core #29242 introduces utility functions to compare two Feerate Diagrams and to evaluate the incentive compatibility of replacing clusters with up to two transactions. These functions lay the groundwork for package replace-by-fee with clusters of up to size two including Topologically Restricted Until Confirmation (TRUC) transactions (aka v3 transactions).

  • ● Core Lightning #7094 removes multiple features that were previously deprecated using Core Lightning’s new deprecation system (see Newsletter #288).

  • ● BDK #1351 makes several changes to how BDK interprets the stop_gap parameter, which controls its gap limit behavior. One change in particular attempts to match the behavior in other wallets where a stop_gap limit of 10 will result in BDK continuing to generate new addresses for scanning for transactions until 10 consecutive addresses have been generated with no matching transactions found.