Today marks the official release of Bitcoin Core 22.0, the 22nd major release of Bitcoin’s original software client launched by Satoshi Nakamoto almost 13 years ago.
Overseen by Bitcoin Core lead maintainer Wladimir van der Laan, this latest major release was developed by well over a hundred contributors in a span of about eight months. The result of roughly 800 pull requests, Bitcoin Core 22.0 is the first major Bitcoin Core release to support the upcoming Taproot protocol upgrade, while also offering several other improvements over previous Bitcoin Core versions.
As an aside, this is also the first Bitcoin Core release to drop the leading 0 from its version number: it’s Bitcoin Core 22.0 — not Bitcoin Core 0.22.0.
Below are some of the more notable changes.
Hardware Wallet Support In The GUI
Hardware wallets are special purpose devices designed to keep private keys secure, that can sign transactions without the private keys ever leaving the device. Still, in order to transact, hardware wallets generally do need to be used in combination with a software wallet. A number of software wallets have the required compatibility to do this, but the Bitcoin Core wallet was for some time not one of them.
This started to change a few years ago: Bitcoin Core has been compatible with hardware wallets since version 0.18.0. However, users had to initially use the command-line interface (CLI) to use this feature. Since Bitcoin Core 0.20.0, users could partially use the graphical user interface (GUI) as well, but this still required some manual copy-pasting to sign transactions.
Bitcoin Core 22.0 is the first Bitcoin Core release to offer full GUI support for hardware wallets. By using the Hardware Wallet Interface (HWI) software as a sort of add-on, Bitcoin Core users will be able to smoothly use the Bitcoin Core wallet in combination with devices from Ledger, Trezor, BitBox, KeepKey, and Coldcard.
I2P Support
One way to de-anonymize Bitcoin users is to analyze the Bitcoin network and track from which nodes specific transactions originate. The IP-addresses associated with these nodes can then be tied to real-world identities.
To protect their privacy, Bitcoin Core users could already connect to the Bitcoin network through the anonymizing Tor network. But Tor is not the only anonymizing network.
The Invisible Internet Project (I2P) is another decentralized, peer-to-peer, anonymous communication network layered on top of the regular internet. Like Tor, it lets users communicate by routing messages across a network, using different layers of encryption for each step in the transmission chain to mask both the message itself, as well as the sender’s and the receiver’s IP-addresses.
(The difference between Tor and I2P is subtle, and beyond the scope of this article. But in short, I2P is said to have a more distributed solution for mapping the network, which is needed for message routing. It would also be better geared towards supporting hidden services, like websites that are only available on the I2P network itself. Tor, in contrast, is said to have better support for exit nodes, which allow users to communicate with the regular internet.)
Bitcoin Core 22.0 now supports connecting to the Bitcoin network through I2P as well. After Tor, this makes I2P the second anonymity network that Bitcoin Core users can utilize to shield their IP address from peers on the Bitcoin network, allowing them to better protect their privacy.
Taproot Support
Bitcoin Core 0.21.1 was the first Bitcoin Core release to include activation logic for the upcoming Taproot protocol upgrade, which will activate this November. Now, Bitcoin Core 22.0 is the first major release to support the upgrade.
Most obviously, this means that Bitcoin Core 22.0 will fully validate the new Taproot rules. From the moment that the upgrade activates this November, all Taproot transactions will be checked for validity according to the new protocol rules.
Additionally, the Bitcoin Core wallet will support the creation of basic Taproot outputs (“addresses”). Bitcoin Core users will be able to accept payments to Taproot outputs that can be spent with a single private key, but that is protected using the Taproot logic.
Of course, this doesn’t actually offer many benefits (if any) compared to what was already possible with the Bitcoin Core wallet software before; the more complex types of smart contracts that Taproot supports will presumably be supported in future Bitcoin Core releases.
Under the hood, Bitcoin Core will also support the creation of Taproot-specific descriptors, which identify Taproot outputs as such. This categorization could benefit applications that rely on the Bitcoin Core software, like (external) wallets.
Testmempool Accept Update
Package relay is an ongoing project to upgrade how transactions are transmitted over the Bitcoin network. Right now, transactions are only relayed if they include a high enough fee to be included in the memory pool (mempool) of Bitcoin nodes. If a transaction doesn’t include a high enough fee, it is not accepted by a node, and not forwarded to other nodes on the Bitcoin network.
This logic differs a little bit from how transactions are selected for inclusion in a new Bitcoin block, however. To determine whether a transaction is included in a block, a transaction’s fee isn’t just considered on its own, but it is also taken into account whether that transaction would help to get other transactions confirmed. If so, the combination of transaction fees is considered.
This allows users to get a transaction with a low fee that is waiting in the mempool “unstuck”, by re-spending the coins in a new transaction with a high fee to compensate. To get the second (higher) fee, 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 like the Lightning Network.
The difference in policy between mempool inclusion and block inclusion can in some cases thwart the CPFP solution. If the first transaction doesn’t include a high enough fee to be accepted in mempools in the first place, a new transaction to re-spend the coins with a higher fee will not be accepted in a block, because it needs the first transaction to also confirm before it is considered valid.
To solve this, package relay would enable that transactions are transmitted over the Bitcoin network in packages. Instead of considering transactions and their fees individually, combinations of transactions would be considered for mempool inclusion, just like it happens for block inclusion.
Bitcoin Core 22.0 includes a step towards realizing package relay: applications connected to Bitcoin Core can test if transactions would be included in their own mempools, by submitting several transactions as a single package. Transmitting or accepting such packages over the peer-to-peer network is not yet supported in this release, however.
Larger Segwit Multisigs
Multi-signature (multisig) outputs are coins that require signatures from multiple private keys in order to be spent. This can for example be two signatures from two different private keys, or three signatures from a set of five private keys, or even seven signatures from a set of eight private keys, and so on.
Multisig can be used for several purposes. One example is to secure funds using several devices so that even if one device is compromised or lost, the coins are still safe and accessible. Similarly, multisig can be used to share control over funds between several people, requiring cooperation between them to spend the coins. In addition, multisig is used in some Layer Two solutions.
The Bitcoin Core software until now supported the creation of multisig outputs for up to 16 keys in Segregated Witness (Segwit) outputs, even though the Bitcoin protocol has no such 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. You can download Bitcoin Core 22.0 here.
