Everything Around Crypto
Bitcoin
$10,739.55
-81.04
(-0.75%)
Ethereum
$355.71
-0.26
(-0.07%)
Ripple
$0.24
0
(+0.08%)
Litecoin
$45.81
-0.38
(-0.82%)
EOS
$2.59
-0.01
(-0.31%)
Cardano
$0.10
-0
(-1.25%)
Stellar
$0.07
0
(+0.98%)
NEO
$20.24
-0.33
(-1.6%)
NEM
$0.12
-0
(-1.26%)
DigitalCash
$67.74
-1.04
(-1.51%)
Tether
$1.00
-0
(-0.1%)
Binance Coin
$27.80
+1.43
(+5.42%)
QTUM
$2.46
+0.06
(+2.63%)
Verge
$0.00
0
(+2.56%)
Ontology
$0.65
-0.02
(-2.58%)
ZCash
$57.33
+0.62
(+1.09%)
Steem
$0.17
0
(+0.26%)
EUR
$1.10
0
(-0.08%)
GBP
$1.23
-0.01
(+0.67%)
JPY
$0.01
-0
(+0.14%)
CHF
$1.03
-0
(+0.45%)
CAD
$0.72
0
(-0.17%)
AUD
$0.66
-0.01
(+0.94%)
ZAR
$0.06
-0
(+0.36%)
RUB
$0.01
-0
(+0.81%)

Bitcoin Core 0.20.0 Released: What’s New

2

Today marks the official release of Bitcoin Core 0.20.0, the 20th major release of Bitcoin’s original software client launched by Satoshi Nakamoto over 11 years ago. 

Overseen by Bitcoin Core lead maintainer Wladimir van der Laan, this latest major release was developed by over 100 contributors in a span of about six months. The result of more than 500 merged pull requests, Bitcoin Core 0.20.0 mostly cleans up and hardens the Bitcoin Core codebase, advances hardware wallet integration, improves network reliability and includes several other improvements.

Here are some of the more notable changes.

Further Hardware Wallet Integration in GUI

Bitcoin Core has been compatible with hardware wallets since version 0.18.0. However, users cannot yet make transactions with a hardware wallet from Bitcoin Core’s graphical user interface (GUI); they must instead use the command-line interface (CLI) to do that.

Bitcoin Core 0.20.0 is taking a step toward hardware wallet integration into the GUI. Users can now create a transaction without a signature in the Bitcoin Core GUI using the partially signed bitcoin transaction (PSBT) format, and copy it to their clipboard. Once copied, they can transfer the transaction to their hardware wallet to sign it — however, this transfer is not yet automated, and broadcasting the transaction still requires using the CLI.

Future Bitcoin Core releases will continue to advance hardware wallet integration.

Asmap for More Reliable Network Connectivity

Bitcoin Core connects to several peers (other Bitcoin nodes) on the Bitcoin network. Bitcoin Core maps other nodes based on their IP addresses, with the intent to establish connections with peers from various regions and Internet Service Providers (ISPs). If a node receives blocks and transactions from peers located all around the world, it decreases the risk that certain data (like a specific transaction) is withheld.

Bitcoin Core currently maps IP addresses by Network Operators’ Groups. However, several of these groups are actually part of the same Autonomous System (AS): clusters of Network Operators’ Groups that share key internet routes, and therefore potentially share the same routing bottlenecks where data could potentially be filtered.

Bitcoin Core 0.20.0 includes a new configuration option called Asmap, which maps IP addresses by Autonomous System Numbers (ASNs). This ensures that the node connects with peers from a range of different ASs, reducing potential network bottlenecks, thus further limiting the risk that specific data is withheld. (Mapping IP addresses into Network Operators’ Groups remains the default configuration for now, however.)

Removal of BIP61 Reject Messages

Reject Messages (BIP61) are notifications that a node returns when a transaction it received from a peer is rejected, and why. (Perhaps because the transaction is invalid, perhaps because it is considered not to include sufficient fee, perhaps there is another reason for the rejection.)

Bitcoin Core developers do not consider the reject messages very useful, however. Most importantly, peers shouldn’t be assumed to reliably return a Reject Message. In other words, if a node doesn’t receive a Reject Message, it doesn’t necessarily mean the transaction was accepted. This limits the usefulness of the messages, while there are better solutions to check that a transaction is valid and includes enough fees. Meanwhile, the messages were making the peer-to-peer protocol more complex, and were taking up bandwidth.

BIP61 Reject Messages had therefore already been disabled by default in Bitcoin Core 0.18.0. Bitcoin 0.20.0 has now removed the feature completely.

Removal of the BIP70 Payment Protocol (and OpenSSL)

The Payment Protocol (BIP 70) was designed several years ago to improve Bitcoin’s payment experience. A user and a merchant could communicate additional details about a payment, such as a human-readable destination address (the name of the merchant) and a refund address in case something went wrong with the purchase.

While Bitcoin Core integrated the Payment Protocol, the standard was never widely adopted. Instead, most wallets still use the more basic URI scheme (BIP21): The clickable link or scannable QR-code format that, for example, communicates the payment address and amount.

Perhaps more importantly than the lack of adoption, the BIP70 Payment Protocol suffered a number of security and privacy vulnerabilities over the years. Most notably, its dependency on the OpenSSL software library for cryptographic functions required a series of short notice emergency upgrades. Some Bitcoin wallets have, for these reasons, rejected implementing BIP70 altogether.

Bitcoin Core 0.19.0 removed the Payment Protocol from the GUI, but users could still compile their node with a special configuration to make use of the feature. Bitcoin Core 0.20.0 has now completely removed the Payment Protocol.

With BIP70 gone (and some other software tweaks to remove the dependency), Bitcoin Core has also been able to completely remove OpenSSL from its codecase.

Dumptxoutset As a First Step Toward Assumeutxo for Fast Bootstrapping

A new remote procedure call (RPC) lets Bitcoin Core 0.20.0 generate a snapshot of the UTXO set, which reflects the state of Bitcoin ownership as recorded on the blockchain at a specific point in time (block height). This snapshot can be shared.

Future Bitcoin Core releases will share such a snapshot when peers first join the network. This allows the new nodes to immediately start participating on the network from the point in time when the snapshot was made, while the entire history of the blockchain is checked in the background. (Like Assumevalid, a similar shortcut, Assumeutxo does come with trust tradeoffs before the entire blockchain is checked, and should until then be used with these tradeoffs in mind.)

For a more extensive list of upgrades, also see the Bitcoin Core 0.20.0 release notes.

Thanks to Sjors Provoost for information and feedback.

Leave A Reply

Your email address will not be published.