It was released on Monday (13) Bitcoin Core 22.0, the 22nd version of the original Bitcoin software created by Satoshi Nakamoto almost 13 years ago.
Supervised by the main developer of Bitcoin Core, Wladimir van der Laan, the new version of the software had the participation of more than one hundred collaborators in a period of eight months.
The result of nearly 800 collaborations, Bitcoin Core 22.0 is the first major release of a version of the software to support Taproot — the most important update BTC has received in four years, scheduled to be activated in November — at the same time which offers several other improvements over previous versions of Bitcoin Core.
Furthermore, this is also the first release to remove the 0 from the beginning of the number that indicates its version: it’s Bitcoin Core 22.0 — not Bitcoin Core 0.22.0.
Below are some of the most notable changes.
GUI hardware wallet support
Hardware wallets are devices designed to keep users’ private keys secure and allow them to 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 version 0.20.0, users could also partially use the graphical user interface (GUI), but this still required a manual copy and paste to sign transactions.
Bitcoin Core 22.0 is the first release to offer full GUI support for hardware portfolios. By using the Hardware Wallet Interface (HWI) software as a kind of add-on, Bitcoin Core users will be able to use the software wallet seamlessly in combination with Ledger, Trezor, BitBox, KeepKey and Coldcard devices.
A way of deanonymize bitcoin users is to analyze the blockchain 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 BTC ecosystem through the Tor anonymity network. But Tor isn’t the only anonymous network out there.
The Invisible Internet Project (I2P) is another decentralized, point-to-point, anonymous communication network layered over the normal Internet.
Like Tor, I2P 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 may have a more distributed solution for mapping the network, which is needed for message routing. It would also be better oriented towards support. to hidden services such as websites that are only available on the I2P network itself. Tor, on the other hand, has better support for outgoing nodes, which allows users to communicate with the normal internet.)
Bitcoin Core 22.0 now also supports connecting to the BTC network via I2P. After Tor, this makes I2P the second anonymity network that users can use to protect their IP address from others on the network, allowing them to better protect their privacy.
Bitcoin Core 0.21.1 was the first Bitcoin Core release to include Taproot activation logic, the next protocol update that 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 previously possible with wallet software; 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 specific descriptors for Taproot, which can identify the outputs of the algorithm. This categorization can benefit applications that depend on the software, such as external wallets.
Improvements in mempool
Packet retransmission 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 added to the memory pool (mempool) of the BTC nodes. If a transaction does not include a high enough rate, it is not accepted by a node and is not forwarded to other nodes on the bitcoin network.
However, this logic differs somewhat from how transactions are selected for inclusion in a new BTC block. 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 also considered.
This allows users to get a transaction with a low rate that is “off”, waiting in the 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 second-tier protocols such as the Lightning Network.
The difference in the policy that determines which transactions are included in the mempool or in a block can, in some cases, frustrate the CPFP solution.
If the first transaction does not include a rate high enough to be accepted in mempools in the first place, a new transaction to re-spend the coins at an even higher rate will not be accepted in a block because it needs the first transaction to be also confirmed before being considered valid.
To solve this, packet retransmission allows transactions to be transmitted over the bitcoin network in packets. Rather than considering transactions and their fees individually, combinations of transactions would be considered for inclusion in the mempool, just as they are for inclusion in a block.
Bitcoin Core 22.0 includes a step for performing 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.
Expansion of Segwit Subscriptions
Multisig outputs represent currencies that require multiple private key signatures 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. An 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. Multisig can also be used in some second-tier solutions.
Until then, Bitcoin Core software supported the creation of multisig outputs for a maximum of 16 keys in Segregated Witness (Segwit) outputs, although the BTC protocol has no such limit. Version 22.0 of the software now expands Segwit’s multisig capability to up to 20 keys.
For more details, see the Bitcoin Core 0.22 release notes. You can download Bitcoin Core 22.0 here.
*This article was translated with permission of the author and originally published in Bitcoin Magazine.
About the author
aaron van windum is technical editor of Bitcoin Magazine. Covers Bitcoin and cryptocurrency market since 2013, with a focus on privacy and scalability.
Translation: Saori Honorato