This week’s newsletter summarizes an analysis of how a node with cluster mempool behaved when tested with all transactions seen on the network in 2023. Also included are our regular sections describing recent updates to clients and services, announcing new releases and release candidates, and summarizing notable changes to popular Bitcoin infrastructure software.

News

• ● What would have happened if cluster mempool had been deployed a year ago? Suhas Daftuar posted to Delving Bitcoin that he recorded every transaction his node received in 2023 and has now run them through a development version of Bitcoin Core with cluster mempool enabled to quantify differences between the existing version and the development version. Some of his findings include:

  • ● The cluster mempool node accepted 0.01% more transactions: “In 2023, [the baseline node’s] ancestor/descendant limits caused over 46k txs to be rejected at some point. […] Only ~14k transactions were rejected due to a cluster size limit being hit.” About 10k of the transactions rejected by the cluster mempool node initially (70% of the rejected 14k) would have later been accepted if they were rebroadcast after some of their ancestors were confirmed, which is expected wallet behavior.

  • ● RBF differences were negligible: “The RBF rules enforced in the two simulations are different, but this turned out to produce a negligible effect on the aggregate acceptance numbers here.” See below for more details.

  • ● Cluster mempool was just as good for miners as legacy transaction selection: Daftuar noted that it is currently the case that nearly every transaction ends up in a block eventually, so both Bitcoin Core’s current transaction selection and cluster mempool transaction selection would actually capture about the same amount in fees. However, in an analysis that Daftuar warns likely overstates results, cluster mempool captured more fees than legacy transaction selection about 73% of the time. Legacy transaction selection was better about 8% of the time. Daftuar concluded, “While it may be inconclusive as to whether cluster mempool is materially better than baseline based on network activity in 2023, it strikes me as very unlikely that cluster mempool is materially worse.”

  Daftuar also considered the effect of cluster mempool on RBF transaction replacement. He starts with an excellent summary of the difference between Bitcoin Core’s current RBF behavior and how RBF would work under cluster mempool (emphasis and links from original):

  The cluster mempool RBF rules are centered around whether the feerate diagram of the mempool would improve after the replacement takes place, while Bitcoin Core’s existing RBF rules are roughly what is described in BIP125 and documented here.

  Unlike BIP125, the proposed [cluster mempool] RBF rule is focused on the result of a replacement. A tx can be better in theory than in practice: maybe it “should” be accepted based on a theoretical understanding of what should be good for the mempool, but if the resulting feerate diagram is worse for any reason (say, because the linearization algorithm is not optimal), then we’ll reject the replacement.

  We’ll also repeat his conclusion from that section of the report, which we feel was well substantiated by the data and analysis he provided:

  Overall, the RBF differences between cluster mempool and existing policy were minimal. Where they differed, the proposed new RBF rules were largely protecting the mempool against replacements which were not incentive compatible—a good change. Yet it’s important to also be aware that in theory, we could see replacements prevented that in an ideal world would be accepted [now], because sometimes seemingly good replacements can trigger suboptimal behavior, which was previously undetected (by BIP125 policy) but would be detected and prevented in the new rules.

  There were no replies to the post as of this writing.

Changes to services and client software

In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.

• ● Phoenix for server announced: Phoenix Wallet announced a simplified, headless Lightning node, phoenixd, focused on sending and receiving payments. phoenixd targets developers, is based on the existing Phoenix Wallet software, and automates channel, peer, and liquidity management.

• ● Mercury Layer adds Lightning swaps: The Mercury Layer statechain uses hold invoices to enable swapping a statechain coin for a Lightning payment.

• ● Stratum V2 Reference Implementation v1.0.0 released: The v1.0.0 release “is a result of improvements in the Stratum V2 specification through the working group collaboration and rigorous testing”.

• ● Teleport Transactions update: A fork of the original Teleport Transactions repository was announced along with several completed updates and improvements.

• ● Bitcoin Keeper v1.2.1 released: The v1.2.1 release adds support for taproot wallets.

• ● BIP-329 label management software: The version 2 release of Labelbase includes a self-hosted option and BIP329 import/export capabilities among other features.

• ● Key agent Sigbash launches: The Sigbash signing service allows users to purchase an xpub for use in a multisig setup that will only PSBT-sign if certain user-specified conditions (hashrate, Bitcoin price, address balance, after a certain time) are met.

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 27.0 is the release of the next major version of the network’s predominant full node implementation. This new version deprecates libbitcoinconsensus (see Newsletters #288 and #297), enables v2 encrypted P2P transport by default (see Newsletter #288), allows the use of opt-in topologically restricted until confirmation (TRUC) transaction policy (also called v3 transaction relay) on test networks (see Newsletter #289), and adds a new coin selection strategy to be used during high feerates (see Newsletter #290). For a complete list of major changes, please see the release notes.

• ● BTCPay Server 1.13.1 is the latest release of this self-hosted payment processor. Since we last covered a BTCPay Server update in Newsletter #262, they’ve made webhooks more extensible, added support for BIP129 multisig wallet import (see Newsletter #281), improved plugin flexibility and begun migrating all altcoin support to plugins, and added support for BBQr-encoded PSBTs (see Newsletter #295), among numerous other new features and bug fixes.

• ● LDK 0.0.122 is the latest release of this library for building LN-enabled applications; it follows the 0.0.121 release that fixes a denial-of-service vulnerability. The latest release also fixes several bugs.

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.

• ● LDK #2704 significantly updates and extends its documentation about its ChannelManager class. The channel manager is “a lightning node’s channel state machine and payment management logic, which facilitates sending, forwarding, and receiving payments through lightning channels.”