A new version of the original Bitcoin software client launched by Satoshi Nakamoto has been released today.
Bitcoin Core 23.0 was worked on by 132 developers over about 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 main changes.
Wallet Updates
Taproot Support
Bitcoin Core now enables the user to choose the new Taproot address type when creating a new wallet. Even though that isn’t the default, as many wallets in the ecosystem can’t send to a Taproot address yet, the user is given the option to create Taproot receiving addresses in newly-created wallets.
The Taproot address created by the Bitcoin Core wallet for receiving bitcoin is a simple, single signature one. Therefore, users won’t automatically save BTC in fees compared to regular Bech32 single-signature addresses, as bigger savings come from porting more complex spending conditions and address setups into the Taproot scheme.
By adding native support for Taproot addresses, Bitcoin Core takes a step in the direction of encouraging a wider adoption of Taproot. As more users opt into the new upgrade’s features, its benefits are able to best permeate through the userbase.
Descriptor Wallets Are Now The Default
Bitcoin Core wallets now default to using descriptors when created, a significant change that promises a better backup and recovery process for bitcoin funds.
Since the advent of hierarchical deterministic (HD) wallets, a Bitcoin wallet will typically use the recovery seeds (usually 12 or 24 words) to generate a master private key. The wallet then uses that master private key to generate a master public key, which can be leveraged to generate a nearly infinite number of receiving addresses through derivation paths, that as the name says, guide the wallet to what path it should follow to correctly derive an address.
Recovering funds in a Bitcoin wallet therefore commonly depends on that derivation path, as most applications today default to HD wallets. (The usage of different derivation paths by wallets is the reason why it is common to see a user attempting to recover funds in a second wallet finding a balance of zero.)
However, descriptor wallets make it much easier for the user to recover any funds by explicitly stating the derivation path in the descriptor. The user is thereby relieved from having to care about the derivation path their wallet used – 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 enables the spotting of possible typos. However, it wasn’t until Bitcoin Core 23.0 that the user could benefit from that.
Bitcoin Core will now alert the user about up to two errors in a Bech32 address. The tool is currently only available on the command line, through the “validateaddress” RPC, though 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 when typing out the address, then the typo-finding tool cannot guarantee success.
The limit of errors the tool commits to finding is important because attempting to find a large number of typos could lead to undesired behavior. If the user typed an address with several mistaken letters, even if the tool could spot all of them it could end up suggesting a totally different address than what the user intended to send to in the first place – a much worse outcome.
Freezing Coins
A Bitcoin Core user has had the option to choose what coins, or unspent transaction outputs (UTXOs), to use in a transaction for years now. But this coin control feature required manual selection of what UTXOs to use every time – a cumbersome and tiring process that is highly prone to error.
Now, Bitcoin Core allows the user to indefinitely “freeze” a UTXO. The freezing process is still a manual one, but the user only needs to do that once and can then rest assured that the coin they froze won’t be automatically spent by Bitcoin Core until the user unfreezes that coin.
Carefully selecting which UTXOs to use in funding a transaction is important to prevent undesirably linking addresses that have conflicting purposes. For example, a user might 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 infer that that user, whom they could know because of the KYC information provided, also owns the non-KYC address and its coins – hurting user privacy.
Changes To P2P Communications
Port 8333 Preference Removed
Broadly speaking, computers need two vital pieces of 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 determine its location, the port number helps inform what type of communication is being done on the internet as each communication protocol usually defaults to a specific port number. As a result, ports enable a computer to run multiple types of traffic at the same time while easily differentiating between them. For example, the web’s HTTP protocol defaults to port 80, while its more secure counterpart HTTPS usually runs on port 443, and email’s SMTP protocol leverages port 25.
With Bitcoin, it is no different. Historically, upon starting Bitcoin Core, computers default to running on port 8333 and looking for peers using that same port.
While ports facilitate the communication between computers on the internet, it also makes it easier for internet service providers (ISPs) to monitor traffic as it is easy to assume what type of communication is being done. In an adversarial setup, an ISP could filter and block certain traffic based on the destination port. Despite not being the most effective censorship mechanism available to ISPs, it is the easiest, and an attacked protocol would need to change its default port of communication to bypass the censoring or throttling.
By removing the port 8333 preference, Bitcoin Core now mitigates the easiest path ISPs have for filtering or blocking Bitcoin traffic. Additionally, nodes not running on port 8333 now will have less friction getting inbound connections from other nodes as the network no longer prioritizes that port.
Support For The CJDNS Network
Bitcoin Core 23.0 also protects users from adversarial ISPs by adding support for CJDNS, a security-enhanced alternative to the standard internet protocol (IP).
CJDNS leverages public-key cryptography to implement an encrypted version of IPv6 – the most recent version of IP. By providing end-to-end encryption natively, CJDNS improves upon IPv6 and IPv4 (the previous IP version that is still widely used) with increased security and privacy as it protects nodes that use it from traffic analysis and filtering.
The addition brings new optionality for users interested in protecting their traffic from prying eyes or increasing the security of their Bitcoin setup. While Tor and I2P exist as alternatives to clearnet IP, CJDNS serves as a complementary option that can enhance robustness for the Bitcoin network and its nodes.
Better Fee Estimations
Bitcoin Core’s built-in fee estimation tool has just gotten a bit more complete.
According to a blog post by John Newbery on the subject, Bitcoin Core’s fee estimation “simply records and reports meaningful statistics about past events, and uses that data to give the user a reasonable estimate of how much fee they need to attach in order to have their transaction included within N blocks,” with N being the number of blocks the user is willing to wait to have their transaction confirmed.
The algorithm calculating such estimates used to take into account all transactions on the mempool, Bitcoin’s “waiting area” for transactions that haven’t yet been included in a block. However, since the introduction of replace-by-fee (RBF) transactions, which enable the user to effectively bump the fee their transaction is pledging to miners in an attempt to get a faster confirmation, Bitcoin Core did not account for the new transaction type when estimating fees out of doubts whether the feature would be widely adopted by users and miners.
Now, with Bitcoin Core 23.0, RBF transactions are taken into account on Bitcoin Core’s fee estimations, providing a more accurate estimate for users leveraging the software for sending transactions.
Support For Tracepoints And Userspace, Statically-Defined Tracing
Bitcoin Core now includes experimental tracepoints in its release binaries for Linux with userspace, 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 makes it possible to keep track of custom fine-grained statistics and monitor otherwise hidden internal node events while having little to no performance impact when unused.
One example where this is useful is to spot and likely prevent attacks. A security researcher could set up multiple nodes and trace the messages received from peers to possibly identify attacks ahead of time.
Thanks to Aaron van Wirdum for information and feedback.
For more details and other changes, see 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.
Comments (No)