It was announced on Thursday (14) the official launch of Bitcoin Core 0.21.0, the 21st major update of the original Bitcoin software client released by Satoshi Nakamoto about 12 years ago.
Supervised by the main maintainer of the current Core team, Wladimir van der Laan, this latest release was developed by more than 100 contributors over a period of about six months.
Resulting from more than 600 requests for combined changes, Bitcoin Core 0.21.0 is one of the biggest releases of Bitcoin Core in recent years, introducing several new features, as well as privacy and performance improvements, while taking a big step towards updating Schnorr and Taproot protocol.
Below are some of the most notable changes.
More organized portfolios
When coins are sent to a Bitcoin address, what really happens behind the scenes is that they are “blocked” in an unspent transaction exit (UTXO), only to be “unlocked” (spent) in a later transaction if the hidden conditions in UTXO are met.
One condition is the inclusion of a valid signature corresponding to a specific public key. But conditions can, for example, also include the inclusion of a secret code, the lapse of a timelock or a combination of signatures (multisig).
So far, Bitcoin Core has been designed to manage the UTXOs in your wallet around their corresponding private keys – although private keys are just one of several potential conditions for spending coins.
Instead, Bitcoin Core 0.21.0 features “descriptor wallets”. Wallets that allow users to categorize their UTXOs based on the types of conditions required to spend them. (For example: a UTXO wallet that requires only a valid subscription and a multisig UTXO wallet.)
Decriptor wallets are especially useful for application developers who design software based on Bitcoin Core. A specific application can now be easily designed to use only a specific type of UTXO, such as multisig UTXOs, and to ignore any non-multisig UTXOs.
Regular users will also notice a difference with this implementation when starting a new Bitcoin Core node. No default wallets will be created when you start Bitcoin Core first. Instead, a new wallet is only created when a user specifically chooses to do so, allowing them to create only the type of wallet they specifically want.
The update also better supports Watch Only wallets: wallets that watch and track certain bitcoins, even if the node does not have the private keys needed to spend them.
Bitcoin Core users who upgrade to Bitcoin Core 0.21.0 will still be able to use their legacy wallet for now. Legacy wallets will eventually be discontinued, meaning that users will need to migrate their legacy wallet to a wallet descriptor, but this will not be strictly necessary until a future Bitcoin Core release.
Light wallets will have better privacy
“Light clients” are Bitcoin wallets and applications that do not download and validate the entire Bitcoin blockchain, but only download and validate parts of blocks and transactions that specifically concern them. This does not optimize security, but it consumes much less resources.
A popular way to do this is with Bloom Filters. In short, Bloom Filters are a cryptographic trick to request relevant data from nodes of more or less random pairs on the network. Unfortunately, however, it has become clear over the years that Bloom Filters are quite hostile to privacy: they essentially reveal all user addresses for the connected (more or less random) node, which can, of course, be operated by someone who wants to pry your balance.
A more recent alternative that preserves the privacy of the Bloom Filter solution much more is called “compact block filtering on the client side” (BIP 157/158). Compact client-side block filtering basically becomes the Bloom Filter trick. Instead of lightweight wallets creating filters to send to complete nodes, complete nodes create filters for each block and send them to light customers upon request.
Light customers then use these filters to find out whether transactions relevant to them may have been included in a bucket. In this case, the lightweight portfolio will fetch the entire block and select all relevant transaction data. (There will be some false positives; blocks that will not have relevant transaction data in them, although the filter would suggest that they do.)
Existing versions of Bitcoin Core can now create filters locally and make them available via a remote procedure call (RPC) for applications running over the node (such as wallets). Bitcoin Core 0.21.0 now also includes the option to make these filters available on the Bitcoin peer-to-peer network upon request. This makes it possible to operate stand-alone light clients using Bloom filters.
Greater privacy when sending transactions
In addition to Bloom Filters, eavesdroppers can also break the privacy of Bitcoin users through network analysis. If they can find out which node a particular transaction originated from, that node's Bitcoin addresses can be linked to its IP address, which in turn can be associated with a real-world identity.
Until now, when the Bitcoin Core nodes transmitted a transaction to the Bitcoin network, they tried to relay the transaction every fifteen minutes, until the transaction was included in a block. This meant that, if these nodes were connected to a “spy” pair, it would be obvious to the eavesdropper that the Bitcoin Core node trying to relay a particular transaction every 15 minutes was also the node from which the transaction originated.
Bitcoin Core 0.21.0 greatly decreases the frequency with which it tries to relay transactions: only once every 12 to 36 hours. Having to retransmit less frequently makes it much more likely that the transaction has been committed since the initial transmission, so the node is less likely to need to retransmit.
In future versions of Bitcoin Core, this privacy leak will be fully corrected. A Bitcoin Core node will then relay only transactions that should have been confirmed based on its own mempool and fee calculations. In addition, it will relay other transactions as well, not just yours.
Tor version 3 support
Due to a recent update to the Tor protocol, a browser that preserves privacy, the new Tor V3 addresses (version 3) are longer than the previous V2 addresses (version 2). V2 addresses are still in use, but will be discontinued in about a year from now.
The discontinuation of V2 addresses would have posed a problem for Bitcoin Core users who wish to use Bitcoin on the privacy network. Bitcoin Core nodes find peers sharing Tor addresses from each other from Bitcoin nodes that use Tor. They shared this via the same message they use to share the regular IP addresses of other nodes.
Although Tor V2 addresses may be "hidden" in the regular IP address format (IPV6), Tor V3 addresses are too long for this; in other words, current messages are too limited to be compatible with the Tor update.
Bitcoin Core 0.21.0 therefore presents a new format for sharing IP / Tor addresses with peers. These messages can be large enough to share Tor V3 addresses.
Taproot and Schnorr signatures are coming
Schnorr / Taproot is about to be the first major Bitcoin protocol update since Segregated Witness (SegWit) in August 2017. Having been in development for more than two years, the Schnorr signature algorithm is considered an overall improvement over the Bitcoin's current ECDSA signature algorithm.
In combination with Taproot – a clever trick to hide various conditions for spending coins – the update promises to offer more smart contract flexibility in a scalable way while preserving privacy.
The Schnorr / Taproot code is now included in Bitcoin Core 0.21.0. This means that it will not be subject to further changes, which, for example, means that application developers can start designing software around the update.
In addition, the changes are now available in Signet (a newer, more reliable testnet variant, used by developers to test new Bitcoin software) and potentially also in Regtests (additional local testnet variants).
Schnorr / Taproot will not, however, be available on the Bitcoin mainnet yet. For this, the update first needs to be activated, which requires an activation logic that is not yet included in this version of Bitcoin Core. Activation logic is expected to be included in a smaller version of Bitcoin Core, possibly sometime in the coming months, with miners already signaling support.
Other improvements and bug fixes
In addition to the above changes, Bitcoin Core 0.21.0 includes several bug fixes and performance improvements that will not be as apparent to regular users. The Bitcoin Core wallet, for example, will move Berkeley DB to the SQLite database, which is more suitable as an application data file and offers several guarantees regarding compatibility, support and testing.
It is also interesting that Bitcoin Core 0.21.0 includes a transaction request review: the new message protocol that Bitcoin nodes use to learn about new transactions is better tested, better specified and easier to maintain and review.
For a more extensive list of updates, see also the Bitcoin Core 0.21.0 release notes or see this blog post from Bitcoin Core contributor Andrew Chow for a more extensive explanation of descriptor portfolios (as well as legacy portfolios) and SQLite (also as Berkeley DB).
Translated and adapted with permission from Aaron Van Wirdum of Bitcoin Magazine, who developed the article with the assistance of Bitcoin developer John Newbery.
Invest in cryptocurrencies with security, high liquidity and the lowest rates in the market.
NovaDAX: the most complete exchange in Brazil with over 25 listed cryptocurrencies and the best customer service score.