A new version of the original Bitcoin software client pioneered by Satoshi Nakamoto was released today.
Bitcoin Core 23.0 has been worked on by 132 developers for approximately seven months to bring tangible improvements to Bitcoin Core’s wallet, peer-to-peer communication and network, fee estimation and much more.
This article explores some of the key changes.
Bitcoin Core now allows the user to choose the new Taproot address type when creating a new wallet. Although not the default, as many wallets in the ecosystem cannot yet send to a Taproot address, the user has the option to create Taproot receive addresses in newly created wallets.
The Taproot address created by the Bitcoin Core wallet to receive bitcoins is a simple single-sign on address. Therefore, users will not automatically save BTC in fees compared to regular Bech32 single-sign on addresses, as greater savings come from porting more complex spend conditions and address configurations into the Taproot scheme.
By adding native support for Taproot addresses, Bitcoin Core is taking a step in the direction of wider adoption of Taproot. As more and more users opt for the features of the new upgrade, its benefits can better spread to the user base.
Descriptor wallets are now the default
Bitcoin Core wallets now default to descriptors once created, a significant change that promises a better process for saving and recovering bitcoin funds.
Since the advent of hierarchical deterministic (HD) wallets, a Bitcoin wallet typically uses the recovery seeds (usually 12 or 24 words) to generate a master private key. The wallet then uses this master private key to generate a master public key, which can be leveraged to generate an almost infinite number of receive addresses via derivation paths, which, as the name suggests, guide the wallet to the path it must follow to correctly derive an address.
The recovery of funds in a Bitcoin wallet therefore generally depends on this derivation path, since most applications today use HD wallets by default. (Wallets’ use of different derivation paths is why it’s common to see a user attempting to retrieve funds from a second wallet finding a balance of zero.)
However, descriptor wallets make it much easier for the user to recover the funds by explicitly indicating the derivation path in the descriptor. This relieves the user of having to worry about which derivation path their wallet uses – a big improvement in user experience (UX).
Typos on Bech32 addresses can now be spotted
Bech32 addresses, the format in which the address begins with “bc1”, have an interesting property that helps to catch possible typos. However, it took until Bitcoin Core 23.0 for the user to benefit from it.
Bitcoin Core will now alert the user to up to two errors in a Bech32 address. The tool is currently only available on the command line, via the “validateaddress” RPC, although there are plans to integrate it into the graphical user interface (GUI) in the future. If more than two errors are made by the user while entering the address, the typo finder cannot guarantee success.
The limit of errors that the tool commits to finding is important because trying to find a large number of typos can lead to unwanted behavior. If the user typed in an address with several wrong letters, even if the tool could spot them all, it might end up suggesting a totally different address than the one the user intended to send to in the first place – a much worse result.
A Bitcoin Core user has had the ability to choose which coins, or unspent transaction outputs (UTXO), to use in a transaction for years now. But this part-checking feature required manual selection of which UTXOs to use each time – a time-consuming and tiring process that is highly error-prone.
Now, Bitcoin Core allows the user to “freeze” a UTXO indefinitely. The freezing process is still manual, but the user only needs to do it once and can then be assured that the coin they have frozen will not be automatically spent by Bitcoin Core until the user unlocks this room.
It is important to carefully select which UTXOs to use to fund a transaction to avoid undesirably linking addresses with conflicting purposes. For example, a user may not want to join UTXOs they obtained through know-your-customer (KYC) methods with non-KYC coins. If they did, any observer of the blockchain would be able to deduce that this user, whom they might know due to the KYC information provided, also owns the non-KYC address and its coins, which is life-threatening. private to users.
Changes to P2P Communications
Port 8333 preference removed
Generally speaking, computers need two pieces of vital information to communicate with each other on the Internet: an IP address and a port number. While the IP address serves as an identifier for a computer in a network, helping to determine its location, the port number helps to inform about the type of communication taking place on the Internet, since each communication protocol generally uses by default a specific port number. Therefore, ports allow a computer to run multiple types of traffic at the same time while easily differentiating between them. For example, the web’s HTTP protocol uses port 80 by default, while its more secure counterpart HTTPS typically runs on port 443, and email’s SMTP protocol uses port 25.
With Bitcoin, it’s no different. Historically, when Bitcoin Core started, computers would run on port 8333 by default and look for peers using that same port.
Although ports make it easier for computers to communicate on the Internet, they also make it easier for Internet Service Providers (ISPs) to monitor traffic because it’s easy to assume what kind of communication is going on. In an adversarial configuration, an ISP could filter and block certain traffic based on destination port. While not the most effective censorship mechanism available to ISPs, it is the simplest, and an attacked protocol would have to change its default communication port to circumvent the censorship or throttling.
By removing the port 8333 preference, Bitcoin Core now mitigates the easiest path ISPs have to filter or block Bitcoin traffic. Additionally, nodes not running on port 8333 will now have less friction getting incoming connections from other nodes, as the network no longer prioritizes this port.
CJDNS network support
Bitcoin Core 23.0 also protects users from opposing ISPs by adding support for CJDNS, a secure alternative to standard Internet Protocol (IP).
CJDNS leverages public key cryptography to implement an encrypted version of IPv6 – the newest version of IP. By providing end-to-end encryption natively, CJDNS enhances IPv6 and IPv4 (the previous IP version which is still widely used) with increased security and privacy as it protects the nodes using it from analysis and traffic filtering.
This addition brings new options for users wishing to protect their traffic from prying eyes or increase the security of their Bitcoin setup. While Tor and I2P exist as alternatives to Clearnet IP, CJDNS serves as a complementary option that can improve the robustness of the Bitcoin network and its nodes.
Best Fee Estimates
Bitcoin Core’s built-in fee estimator just got a little more comprehensive.
According to a blog post by John Newbery on the subject, the Bitcoin Core Fee Estimator “simply records and reports meaningful statistics about past events, and uses this data to give the user a reasonable estimate of the amount of the fee. that he must attach to have their transaction included in NOT blocks”, with NOT being the number of blocks the user is willing to wait for their transaction to be confirmed.
The algorithm calculating these estimates took into account all transactions on the mempool, Bitcoin’s “waiting area” for transactions that have not yet been included in a block. However, since the introduction of Fee Replacement (RBF) transactions, which effectively allow the user to increase the fee their transaction promises miners in an effort to gain faster confirmation, Bitcoin Core has not not taken into account the new type of transaction. when estimating fees by doubt that the feature would be widely adopted by users and miners.
Now, with Bitcoin Core 23.0, RBF transactions are factored into Bitcoin Core fee estimates, providing a more accurate estimate for users using the software to send transactions.
Support for tracepoints and userspace, statically defined tracing
Bitcoin Core now includes experimental tracepoints in its release binaries for Linux with user space, statically defined tracing (USDT).
USDT allows users to get detailed information from their node that can be used for review, debugging, and monitoring. The feature tracks fine-grained custom statistics and monitors otherwise hidden internal node events while having little to no performance impact when not in use.
An example where this is useful is spotting and possibly preventing attacks. A security researcher could set up multiple nodes and track messages received from peers to possibly identify attacks in advance.
Thanks to Aaron van Wirdum for information and comments.
For more details and other changes, check out the Bitcoin Core 23.0 release notes. To download Bitcoin Core 23.0, navigate here. Details about Bitcoin Core 23.0 are also explained in audio in the Bitcoin Explained Podcast Episode 56.