Bitcoin Core versions with a full number are usually “major releases” — they bring extensive innovations that the developers polish through the following versions until the next full number. So it is with 24.0.

The release 24.0 is overshadowed by a controversy about Replace-By-Fee. However, the release contains some other exciting news, which I will present first, before I turn to the controversy.

1. Miniscript

One of the most promising new features is the implementation of Miniscript. Miniscript is a kind of programming language to write bitcoin scripts.

Of course, it is already possible to “program” bitcoin transactions through scripts. But this is complex, tedious and in inexperienced hands also unsafe. Miniscript simplifies and structures this by introducing so-called descriptors that map specific scripts.

The initial implementation introduced for Bitcoin 24.0 is very rudimentary. Users can create a new wallet that can import miniscript descriptors for P2SWH addresses. The wallet can receive bitcoins, but not send them yet.

The feature is thus only intended for developers who are willing to experiment. There is still a long way to go before it is fully implemented in user practice. But the first step has been taken.

2. Sendall and random inputs

With the following two changes, Core gives users tools to strengthen their privacy.

First, there is the RPC call “Sendall.” This sends all bitcoins in the entire wallet or in selected UTXOs to a receiving address. This can be handy. Most importantly, it helps improve privacy, as no change is created in the process.

Second, Core now randomly selects the UTXOs that a transaction issues. This makes it more difficult for blockchain analysts to identify a wallet based on UTXO selection and detect patterns that identify change.

For this, the wallet will select a random number between the single and triple size of the payment. This number will then determine which UTXO it will issue. With this, sometimes the UTXO will only be a little larger than the amount, while other times it will be significantly larger.

Now we come to the controversial new feature of Core 24.0: the expansion of Replace-By-Fee (RBF) to Full-RBF.

In case you’re not familiar with it, RBF allows you to replace one transaction with another at a higher fee. This has always been possible in itself — even with a different receiver — because miners can pick and choose which transactions they confirm. However, it has long been made more difficult, for example by the rule that nodes only forward the transaction they saw first (first-lake rule).

RBF now dismantles this rule on the one hand, and allows users on the other hand to mark transactions as RBF and replace them with another one. This helps, for example, to increase fees after the fact, which Core maps to a “bumb fee” button in the user interface.

Core 24.0 now brings two new features into play, which the term “full-RBF” refers to: First, users can configure their nodes to replace transactions even if they are not marked with the RBF flag. This option is turned off by default. Second, RBF transactions become the default instead of being enabled as before.

This new feature was discussed lively and controversially back in October. I have already reported about it.

For example, Sergej Kotlar of Bitrefill complained that his voucher card marketplace would be forced by Core 24.0 not to accept unconfirmed onchain transactions, instead instructing users to use either an escrow wallet or Lightning.

In general, the change was unusually controversial for Core. John Carvalho of Bitrefill, for instance, complains that several respected developers, such as Suhas Daftuar, David Harding, Antoine Raird, and Jon Atack, think it was wrong to introduce full-RBF in Core 24.0. With the mempool currently emptier than it has been in a long time, there would have been no need to force it.

It so happens that Core provides argumentative justification for the change in the release notes, which happens very rarely: Some Bitcoin service providers, the release notes say, expected the first version of an unconfirmed transaction they see to be confirmed. But this is not covered by the Bitcoin protocol, it said. Miners could replace that transaction at any time. Nevertheless, several traders and service providers relied on this assumption today. Core developers strongly advised against it.

Thus, the core developers are taking on a risk assessment for the traders and service providers. This, as Sergej Kotlar points out in the mailing list, doesn’t really meet reality: “I think we had one incident in eight years of operation that someone successfully fooled our server into accepting a payment that ended up not being confirmed.” It is possible in most cases, even in the more delicate trade of gift cards, to control the risk of a double spend. In other words, it was. Core 24.0 makes that risk control much more difficult, if not impossible.

In the long run, however, full-RBF is less controversial than it might seem. Pretty much everyone agrees that real-time transactions should go through Lightning rather than onchain, and that, especially as block rewards decrease, it will be necessary to make the risks of double spends transparent rather than lulling users into a false sense of security. The only question is whether it would have been necessary now.