486 total views
Today (January 14), Bitcoin Core 0.21.0 was officially released , which is the 21st major version of the original Bitcoin software client launched by Satoshi Nakamoto about 12 years ago.
Under the supervision of Bitcoin Core chief maintainer Wladimir van der Laan, this latest major version was developed by more than one hundred contributors in approximately six months. Bitcoin Core 0.21.0 is one of the largest Bitcoin Core versions in recent years. It introduces various new features, as well as privacy and performance improvements. It also takes a big step towards the upgrade of the Schnorr/Taproot protocol.
The following are some of the more significant changes.
1. Descriptor wallet
When coins are sent to a Bitcoin address, what actually happens is that they will be “locked” in an unspent transaction output (UTXO), and only when they meet the hidden conditions in UTXO can they be used in future transactions. “Unlock” (cost). One of the typical conditions is to include a valid signature corresponding to a specific public key. But conditions can also include combinations such as secret codes, invalidation of time locks, or signatures (multi-signature).
Until now, Bitcoin Core has been designed to manage the UTXOs in the wallet around its corresponding private key-although the private key is only one of several potential conditions for spending tokens. This time, Bitcoin Core 0.21.0 introduced “Descriptor Wallets” (Descriptor Wallets). Descriptor wallets allow users to categorize UTXO according to the type of conditions required to spend UTXO. (For example: one wallet is used for UTXOs that require only valid signatures, and another wallet is used for multi-signature UTXOs).
Descriptor wallets are particularly useful for application developers who design software on Bitcoin Core. Now, a specific application can be easily designed to use only specific types of UTXOs, such as multi-sign UTXOs, and ignore any non-multi-sign UTXOs.
Ordinary users may also notice the difference after the implementation of the current descriptor wallet. Perhaps most notably, when a new Bitcoin Core node is launched, the default wallet will not be created. Instead, a new wallet will be created only when the user specifically chooses to create a new wallet, and they will be allowed to create only the type of wallet that they specifically need. In addition, descriptor wallets also better support Watch Only wallets: even if nodes do not use the private keys they need, they will track certain UTXOs.
Bitcoin Core users who upgraded to Bitcoin Core 0.21.0 can still use their traditional wallets. (Traditional wallets will eventually be abandoned, which means users will need to migrate their traditional wallets to descriptor wallets, but this is not strictly necessary until the future Bitcoin Core release.)
2. Provide compact block filtering services on peer-to-peer networks
“Light clients” refer to bitcoin wallets and applications that do not download and verify the entire bitcoin block, but only download and verify specific blocks and transactions involved. This is not the best security method, but it consumes much less resources.
Among them, a popular way is to use Bloom Filters. In short, Bloom Filters are an encryption technique used to request relevant data from more or less random peer nodes on the network. Unfortunately, over the years, people have clearly realized that Bloom Filters are quite unfriendly to privacy: they basically reveal all the addresses of users to (more or less random) peer nodes, and of course, also Spy operations that can be violated by privacy.
Compared with the Bloom Filter solution, a newer and more privacy-protected alternative is called “Compact Client Block Filtering” (BIP 157/158). It essentially subverts the techniques of Bloom Filter. It is not so much that the light wallet creates a filter and sends it to the full node, it is more that the full node creates a filter for each block and sends these filters to the light client according to the request. Then, light clients use these filters to figure out whether their related transactions may have been included in a block. If so, the light wallet will get the entire block and pick out any relevant transaction data from it. (There will be some false positives; even if the filter suggests that there may be blocks with relevant transaction data, it may not contain relevant transaction data.)
The existing Bitcoin Core version can already create filters locally and provide filters for applications (such as wallets) running on top of nodes through remote procedure calls (RPC). Bitcoin Core 0.21.0 now also includes an option to provide these filters on Bitcoin’s peer-to-peer network upon request. In other words, it is now possible to operate independent light clients that use bloom filters.
3. Fewer replay attempts
In addition to Bloom Filters, snoopers can also crack the privacy of Bitcoin users through network analysis. If they can find out which node a certain transaction comes from, then the Bitcoin address of that node can be linked to its IP address, and the IP address can be linked to a real-world identity.
Until now, when Bitcoin Core nodes broadcast a transaction to the Bitcoin network, they will try to rebroadcast the transaction every 15 minutes until the transaction is included in a block. This means that if these Bitcoin Core nodes are connected to a snooping peer, it is obvious to the snoopers that the Bitcoin Core node that tries to replay a transaction every 15 minutes is the origin node of the transaction.
Bitcoin Core 0.21.0 has greatly reduced the frequency of its attempts to replay transactions: from the original frequency adjustment to only once every 12 to 36 hours. The frequency of rebroadcasts has to be reduced, which greatly increases the possibility of transactions being confirmed from the initial broadcast, so the node does not need to rebroadcast at all.
In future versions of Bitcoin Core, this privacy leak will be completely repaired. At that time, Bitcoin Core nodes will only replay transactions that should be confirmed based on their mempool and fee calculations. In addition, it will replay other transactions, not just its own transactions.
4. Support Tor V3
Due to the recent upgrade of the privacy protection Tor protocol, the Tor address of the new V3 version is longer than the address of the previous V2 version. Currently, the V2 address is still in use, but will be obsolete in about a year.
Abandoning V2 addresses will cause problems for Bitcoin Core users who want to use Bitcoin through a private network. Originally, Bitcoin Core nodes searched for peers by sharing the Tor addresses of Bitcoin nodes known to use Tor. They share this IP address by sharing the same information of the regular IP address of other nodes. Although the Tor V2 address can be “hidden” in the regular IP address format (IPV6), the Tor V3 address is too long, that is, the current information is too limited to be compatible with Tor upgrades.
Therefore, Bitcoin Core 0.21.0 introduced a new format to share IP/Tor addresses with peers. These messages can be as large as the shared Tor V3 address.
5. Schnorr/Taproot code and Signet/Regtest deployment
Schnorr/Taproot will be Bitcoin’s first protocol upgrade since Segregated Witness (SegWit) in August 2017. The Schnorr signature algorithm has been developed for more than two years and is considered to be a comprehensive improvement to Bitcoin’s current ECDSA signature algorithm. Combined with Taproot (a clever technique that hides various conditions for spending tokens in a cryptographic hash tree), this upgrade is expected to provide more smart contract flexibility in a scalable and privacy-preserving way.
The Schnorr/Taproot code is now included in Bitcoin Core 0.21.0. Unless there are unexpected developments, it will not have any changes, that is, application developers can already start designing software around upgrades. In addition, Schnorr/Taproot is now available on Signet (a newer and more reliable variant of the testnet that developers can use to test new Bitcoin software), and it may also be used on Regtests (an additional local testnet) Variant).
However, Schnorr/Taproot cannot be used on the Bitcoin mainnet yet. To this end, the upgrade first requires activation, and activation requires activation logic. However, this Bitcoin Core version does not contain activation logic and is expected to be included in a small version of Bitcoin Core sometime in the next few months.
In addition to the above changes, Bitcoin Core 0.21.0 also includes various bug fixes and performance improvements. For ordinary users, these changes will not be so obvious.
For example, Bitcoin Core wallet will switch from using Berkeley DB to SQLite database, which is more suitable as an application data file and provides multiple guarantees in terms of compatibility, support and testing.
It is worth noting that Bitcoin Core 0.21.0 also includes an overhaul of transaction requests : the new message protocol used by Bitcoin nodes to understand new transactions has been better tested, better regulated, and easier to maintain and review.