Monday (13/09) marked the official release of Bitcoin Core 22.0, the 22nd major release of the original Bitcoin software client released by Satoshi Nakamoto almost 13 years ago.
Overseen by the main maintainer of Bitcoin Core, Wladimir van der Laan, this latest major release was developed by over a hundred contributors in a period of about eight months.
Resulting from around 800 pull requests (suggested changes), Bitcoin Core 22.0 is the first major release of Bitcoin Core to support the upcoming Taproot protocol update, while offering several other improvements over previous versions of Bitcoin Core.
As an aside, this is also the first Bitcoin Core release to strip the main 0 from its version number: it’s Bitcoin Core 22.0 – not Bitcoin Core 0.22.0.
Below are some of the most notable changes.
Hardware wallet support in the graphical user interface
Hardware wallets are devices designed to keep private keys secure, which can sign transactions without the private keys leaving the device. Still, to carry out transactions, hardware wallets often need to be used in combination with a software wallet. Several software wallets have the compatibility needed to do this, but the Bitcoin Core wallet for some time has not been one of them.
This started to change a few years ago: Bitcoin Core is compatible with hardware wallets since version 0.18.0. However, users initially had to use the command-line interface (CLI) to use this feature. As of Bitcoin Core 0.20.0, users could also partially use the graphical user interface (GUI), but this still required some manual copying and pasting to sign transactions.
Bitcoin Core 22.0 is the first Bitcoin Core release to offer full GUI support for hardware wallets. Using Hardware Wallet Interface (HWI) software as a kind of add-on, Bitcoin Core users will be able to use the Bitcoin Core wallet seamlessly in combination with Ledger, Trezor, BitBox, KeepKey and Coldcard devices.
Invisible Internet Project (I2P) Support
One way to deanonymize Bitcoin users is to analyze the Bitcoin network and track from which nodes specific transactions originate. The IP addresses associated with these nodes can be linked to real-world identities.
To protect their privacy, Bitcoin Core users were already able to connect to the Bitcoin network through the anonymous Tor network. But Tor isn’t the only anonymous network.
The Invisible Internet Project (I2P) is another decentralized, point-to-point, anonymous communication network layered over the normal Internet. Like Tor, it allows users to communicate by routing messages across a network, using different layers of encryption for each step in the transmission chain to mask the message itself, as well as the IP addresses of the sender and recipient.
(The difference between Tor and I2P is subtle and beyond the scope of this article. But in summary, I2P is said to have a more distributed solution for mapping the network, which is needed for message routing. It would also be better oriented towards supporting hidden services, such as websites that are only available on the I2P network itself. Tor, on the other hand, has better support for outbound nodes, which allow users to communicate with the normal Internet.)
Bitcoin Core 22.0 now also supports connecting to the Bitcoin network via I2P. After Tor, this makes I2P the second anonymity network that Bitcoin Core users can use to protect their IP address from their peers on the Bitcoin network, allowing them to better protect their privacy.
Bitcoin Core 0.21.1 was the first Bitcoin Core release to include activation logic for the upcoming Taproot protocol update, which will be activated in November of this year. Bitcoin Core 22.0 is now the first major release to support the update.
Obviously, this means that Bitcoin Core 22.0 will fully validate the new Taproot rules. From the moment the update is activated in November, all Taproot transactions will be checked for validity according to the new protocol rules.
In addition, the Bitcoin Core wallet will support the creation of basic Taproot outputs (“addresses”). Bitcoin Core users will be able to accept payments for Taproot outputs that can be spent with a single private key, but which is protected using Taproot logic.
Of course, this doesn’t offer many benefits (if any) compared to what was possible with Bitcoin Core wallet software before; the more complex types of smart contracts that Taproot supports will presumably be supported in future versions of Bitcoin Core.
Behind the scenes, Bitcoin Core will also support the creation of Taproot-specific descriptors, which identify Taproot outputs as such. This categorization can benefit applications that rely on Bitcoin Core software, such as (external) wallets.
Update in mempool
Packet relay is an ongoing project to update the way transactions are transmitted over the Bitcoin network. Currently, transactions are only retransmitted if they include a rate high enough to be included in the memory pool (mempool) of the Bitcoin nodes. If a transaction does not include a high enough fee, it is not accepted by one node and is not forwarded to other nodes in the Bitcoin network.
This logic differs somewhat from how transactions are selected for inclusion in a new Bitcoin block, however. To determine whether a transaction is included in a block, the fee for a transaction is not only considered by itself, but it is also taken into account whether that transaction would help to get confirmation from other transactions. In this case, the combination of transaction fees is considered.
This allows users to get a transaction with a low rate that is waiting in the “unlocked” mempool, re-spending the coins on a new transaction with a high rate to compensate. To get the second (higher) rate, miners will want to accept both transactions at the same time. This trick is called Child-Pays-For-Parent (CPFP) and can be particularly useful in the context of some Layer Two protocols such as Lightning Network.
The policy difference between mempool inclusion and block inclusion can, in some cases, frustrate the CPFP solution. If the first transaction does not include a rate high enough to be accepted into mempools in the first place, a new transaction to re-spend the higher rate coins will not be accepted in a block because it needs the first transaction confirmed before it is considered valid.
To solve this, packet retransmission would allow transactions to be transmitted over the Bitcoin network in packets. Instead of considering transactions and their fees individually, transaction combinations would be considered for mempool inclusion, just as they are for block inclusion.
Bitcoin Core 22.0 includes a step to perform packet relay: applications connected to Bitcoin Core can test whether transactions would be included in their own mempools by sending multiple transactions as a single packet. However, transmission or acceptance of such packets over the peer-to-peer network is not yet supported in this release.
Larger Multi Segwit Subscriptions
Multisignature outputs (multisig) are currencies that require signatures of multiple private keys to be spent. This could be, for example, two signatures of two different private keys, or three signatures of a set of five private keys, or even seven signatures of a set of eight private keys, and so on.
Multisig can be used for a variety of purposes. One example is securing funds using multiple devices so that even if one device is compromised or lost, the coins are still safe and accessible. Likewise, multisig can be used to share control over funds between multiple people, requiring cooperation between them to spend the coins. Also, multisig is used in some second-tier solutions.
Bitcoin Core software has so far supported the creation of multisig outputs for up to 16 keys in Segregated Witness (Segwit) outputs, although the Bitcoin protocol does not have such a limit. Bitcoin Core 22.0 now expands Segwit multisig capability to 20 keys.
For more details and other changes, see the Bitcoin Core 0.22 release notes.
Text originally published in BitcoinMagazine by Aaron Van Wirdum.