Today marks the official release of Bitcoin Core 0.21.0, the 21st major release of Bitcoin’s original software client launched by Satoshi Nakamoto about 12 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 six months. The result of over 600 merged pull requests, Bitcoin Core 0.21.0 is one of the biggest Bitcoin Core releases in recent years, introducing various new features as well as privacy and performance improvements, while taking a big step towards the Schnorr/Taproot protocol upgrade.
Below are some of the more notable changes.
Descriptor Wallets
When coins are sent to a Bitcoin address, what actually happens under the hood is that they are “locked up” in an unspent transaction output (UTXO), to only be “unlocked” (spent) in a later transaction if the conditions hidden in the UTXO are met. A typical condition is the inclusion of a valid signature corresponding to a specific public key. But conditions can for example also consist of the inclusion of a secret code, the lapse of a timelock or a combination of signatures (multisig).
Until now, Bitcoin Core was designed to manage the UTXOs in its wallet around their corresponding private keys — even though private keys are just one of several potential conditions for spending coins. Bitcoin Core 0.21.0 instead introduces “descriptor wallets.” Descriptor wallets let users categorize their UTXOs based on the types of conditions that are required to spend them. (For example: one wallet for UTXOs that just require a valid signature, and one wallet for multisig UTXOs.)
Descriptor wallets are especially useful for application developers who design software on top of Bitcoin Core. A particular application can now easily be designed to utilize only a specific type of UTXO, like multisig UTXOs, and ignore any non-multisig UTXOs.
Regular users may also notice a difference now that descriptor wallets are implemented. Perhaps most notably, no default wallet will be created when a new Bitcoin Core node is started up. Instead, a new wallet is only created when a user specifically chooses to do so, allowing them to create only the specifically desired type of wallet. Descriptor wallets also better support Watch Only wallets: wallets that keep track of certain UTXOs even though the node doesn’t have the private keys needed to spend them.
Bitcoin Core users that upgrade to Bitcoin Core 0.21.0 will still be able to use their legacy wallet for now. (Legacy wallets will eventually be deprecated, meaning users will need to migrate their legacy wallet to a descriptor wallet, but this won’t be strictly necessary until a future Bitcoin Core release.)
Serving Compact Block Filters Over The Peer-To-Peer Network
“Light clients” are Bitcoin wallets and applications that don’t download and validate the entire Bitcoin blockchain, but instead only download and validate parts of blocks and transactions that concern them specifically. This is not optimally secure, but is much less resource intensive.
One popular way to do this is with Bloom Filters. In short, Bloom Filters are a cryptographic trick to request relevant data from more or less random peer nodes on the network. Unfortunately, however, it has become clear over the years that Bloom Filters are rather privacy-unfriendly: they essentially reveal all of the user’s addresses to the (more or less random) peer node, which could of course be operated by a privacy-invading snoop.
A newer and much more privacy-preserving alternative to the Bloom Filter solution is called “compact client-side block filtering” (BIP 157/158). Compact client-side block filtering essentially turns the Bloom Filter trick on its head. Instead of light wallets creating filters to send to full nodes, full nodes create filters for each block and send these to light clients on request. Light clients then use these filters to figure out if transactions relevant to them may have been included in a block. If so, the light wallet will fetch the whole block and pick any relevant transaction data out of it. (There will be some false positives; blocks that won’t have relevant transaction data in them even though the filter suggested they might.)
Existing Bitcoin Core releases could already create the filters locally, and make them available through a remote procedure call (RPC) for applications running on top of the node (like wallets). Bitcoin Core 0.21.0 now also includes the option to make these filters available over Bitcoin’s peer-to-peer network on request. This makes it possible to now operate standalone light clients that use bloom filters.
Fewer Rebroadcast Attempts
Besides Bloom Filters, snoops can also break the privacy of Bitcoin users through network analysis. If they can figure out from which node a particular transaction originated, that node’s Bitcoin address(es) can be tied to its IP address, which can in turn be associated with a real-world identity.
Until now, when Bitcoin Core nodes broadcasted a transaction to the Bitcoin network, they’d try to re-broadcast the transaction every fifteen minutes, until the transaction was included in a block. This meant that if these Bitcoin Core nodes were connected to a snooping peer, it would be obvious for the snoop that the Bitcoin Core node trying to re-broadcast a certain transaction every 15 minutes was also the node where that transaction originated.
Bitcoin Core 0.21.0 greatly diminishes the frequency with which it tries to re-broadcast transactions: only once every 12 to 36 hours. Having to re-broadcast less frequently makes it much more likely that the transaction has been confirmed since the initial broadcast, so the node is less likely to have to re-broadcast at all.
In future Bitcoin Core releases, this privacy leak will be fixed entirely. A Bitcoin Core node will then only re-broadcast transactions that should have been confirmed based on its own mempool and fee calculations. Furthermore, it will re-broadcast other transactions as well, not just its own.
Tor V3 Support
Due to a recent upgrade to the privacy-preserving Tor protocol, new V3 (version 3) Tor-addresses are longer than the V2 (version 2) addresses that came before them. V2 addresses are still in use, but will be deprecated in about a year from now.
Deprecation of V2 addresses would have posed a problem for Bitcoin Core users who want to use Bitcoin over the privacy network. Bitcoin Core nodes find peers by sharing with each other Tor addresses of known Tor-using Bitcoin nodes. They shared this through the same message they use to share other nodes’ regular IP addresses. While Tor V2 addresses could be “hidden” in the regular IP address format (IPV6), Tor V3 addresses are too long for that; in other words, the current messages are too limited to be compatible with the Tor upgrade.
Bitcoin Core 0.21.0 therefore introduces a new format to share IP/Tor addresses with peers. These messages can be big enough to share the Tor V3 addresses.
Schnorr/Taproot Code and Signet/Regtest Deployment
Schnorr/Taproot is poised to be Bitcoin’s first protocol upgrade since Segregated Witness (SegWit) in August 2017. Having been in development for well over two years, the Schnorr signature algorithm is considered an all-round improvement over Bitcoin’s current ECDSA signature algorithm. In combination with Taproot — a clever trick to hide various conditions to spend coins in a cryptographic hash tree — the upgrade promises to offer more smart contract flexibility in a scalable and privacy-preserving manner.
The Schnorr/Taproot code is now included in Bitcoin Core 0.21.0. Barring unexpected developments, this means it will not be subject to any more change, which for example means that application developers could start designing software around the upgrade. In addition, Schnorr/Taproot is now available on Signet (a newer and more reliable variant of testnet, used by developers to test new Bitcoin software) and potentially also on Regtests (additional local testnet variants).
Schnorr/Taproot will not, however, be available on Bitcoin’s mainnet just yet. For this, the upgrade will first need to activate, which requires activation logic that isn’t yet included in this Bitcoin Core release. Activation logic is expected to be included in a minor Bitcoin Core release, possibly somewhere in the next months.
Other…
On top of the changes above, Bitcoin Core 0.21.0 includes various bug fixes and performance improvements that won’t be as apparent for regular users. The Bitcoin Core wallet will for example switch from using the Berkeley DB to the SQLite database, which is better suited as an application data file and offers several guarantees in regards of compatibility, support and testing. Of interest is also that Bitcoin Core 0.21.0 includes a transaction request overhaul: 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 upgrades, also see the Bitcoin Core 0.21.0 release notes, or see this blog post by Bitcoin Core contributor Andrew Chow for a more extensive explanation of descriptor wallets (as well as legacy wallets) and SQLite (as well as Berkeley DB).
Thanks to John Newbery for information and feedback.
The post Bitcoin Core 0.21.0 Released: What’s New appeared first on Bitcoin Magazine.
