Bitcoin Core 0.22.0 and 0.21.2

A «full node» is a program that fully validates Bitcoin transactions and blocks. Almost all full nodes also help the network by accepting transactions and blocks from other full nodes, validating those transactions and blocks, and then relaying them to further full nodes.

Most full nodes also serve lightweight clients by allowing them to transmit their transactions to the network and by notifying them when a transaction affects their wallet. If not enough nodes perform this function, clients won’t be able to connect through the peer-to-peer network—they’ll have to use centralized services instead.

Many people and organizations, Openstream included, volunteer to run full nodes using spare computing and bandwidth resources—but more volunteers are needed to allow Bitcoin to continue to grow.

22.0 Release Notes

• On September 13, 2021, Bitcoin Core 22.0 was released, it is available from: bitcoincore.org/bin/bitcoin-core-22.0/
• This release includes new features, various bug fixes and performance improvements, as well as updated translations.
• Bugs can be reported using the issue tracker at GitHub: github.com/bitcoin/bitcoin/issues
• To receive security and update notifications, subscribe to: bitcoincore.org/en/list/announcements/join/

At the time of writing this blog post around 18% of reachable nodes in the Bitcoin network crawled by Bitnodes are using Bitcoin Core 0.22.0. Over 70% are using Bitcoin Core 0.21.0 and above. Version 0.21.0 was released in January 2021.

How to Upgrade

If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes in some cases), then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux).

Upgrading directly from a version of Bitcoin Core that has reached its EOL is possible, but it might take some time if the data directory needs to be migrated. Old wallet versions of Bitcoin Core are generally supported.

Compatibility

Bitcoin Core is supported and extensively tested on operating systems using the Linux kernel, macOS 10.14+, and Windows 7 and newer. Bitcoin Core should also work on most other Unix-like systems but is not as frequently tested on them. It is not recommended to use Bitcoin Core on unsupported systems.

From Bitcoin Core 22.0 onwards, macOS versions earlier than 10.14 are no longer supported.

Notable changes

P2P and network changes

• Added support for running Bitcoin Core as an I2P (Invisible Internet Project) service and connect to such services. See i2p.md for details. (#20685)
• This release removes support for Tor version 2 hidden services in favor of Tor v3 only, as the Tor network dropped support for Tor v2 with the release of Tor version 0.4.6. Henceforth, Bitcoin Core ignores Tor v2 addresses; it neither rumors them over the network to other peers, nor stores them in memory or to peers.dat. (#22050)
• Added NAT-PMP port mapping support via libnatpmp. (#18077)

New and Updated RPCs

• Due to BIP 350 being implemented, behavior for all RPCs that accept addresses is changed when a native witness version 1 (or higher) is passed. These now require a Bech32m encoding instead of a Bech32 one, and Bech32m encoding will be used for such addresses in RPC output as well. No version 1 addresses should be created for mainnet until consensus rules are adopted that give them meaning (as will happen through BIP 341). Once that happens, Bech32m is expected to be used for them, so this shouldn’t affect any production systems, but may be observed on other networks where such addresses already have meaning (like signet). (#20861)
• The getpeerinfo RPC returns two new boolean fields, bip152_hb_to and bip152_hb_from, that respectively indicate whether we selected a peer to be in compact blocks high-bandwidth mode or whether a peer selected us as a compact blocks high-bandwidth peer. High-bandwidth peers send new block announcements via a cmpctblock message rather than the usual inv/headers announcements. See BIP 152 for more details. (#19776)
• getpeerinfo no longer returns the following fields: addnode, banscore, and whitelisted, which were previously deprecated in 0.21. Instead of addnode, the connection_type field returns manual. Instead of whitelisted, the permissions field indicates if the peer has special privileges. The banscore field has simply been removed. (#20755)
• The following RPCs: gettxout, getrawtransaction, decoderawtransaction, decodescript, gettransaction, and REST endpoints: /rest/tx, /rest/getutxos, /rest/block deprecated the following fields (which are no longer returned in the responses by default): addresses, reqSigs. The -deprecatedrpc=addresses flag must be passed for these fields to be included in the RPC response. This flag/option will be available only for this major release, after which the deprecation will be removed entirely. Note that these fields are attributes of the scriptPubKey object returned in the RPC response. However, in the response of decodescript these fields are top-level attributes, and included again as attributes of the scriptPubKey object. (#20286)
• When creating a hex-encoded bitcoin transaction using the bitcoin-tx utility with the -json option set, the following fields: addresses, reqSigs are no longer returned in the tx output of the response. (#20286)
• The listbanned RPC now returns two new numeric fields: ban_duration and time_remaining. Respectively, these new fields indicate the duration of a ban and the time remaining until a ban expires, both in seconds. Additionally, the ban_created field is repositioned to come before banned_until. (#21602)
• The setban RPC can ban onion addresses again. This fixes a regression introduced in version 0.21.0. (#20852)
• The getnodeaddresses RPC now returns a “network” field indicating the network type (ipv4, ipv6, onion, or i2p) for each address. (#21594)
• getnodeaddresses now also accepts a “network” argument (ipv4, ipv6, onion, or i2p) to return only addresses of the specified network. (#21843)
• The testmempoolaccept RPC now accepts multiple transactions (still experimental at the moment, API may be unstable). This is intended for testing transaction packages with dependency relationships; it is not recommended for batch-validating independent transactions. In addition to mempool policy, package policies apply: the list cannot contain more than 25 transactions or have a total size exceeding 101K virtual bytes, and cannot conflict with (spend the same inputs as) each other or the mempool, even if it would be a valid BIP125 replace-by-fee. There are some known limitations to the accuracy of the test accept: it’s possible for testmempoolaccept to return “allowed”=True for a group of transactions, but “too-long-mempool-chain” if they are actually submitted. (#20833)
• addmultisigaddress and createmultisig now support up to 20 keys for Segwit addresses. (#20867)

Changes to Wallet or GUI related RPCs can be found in the GUI or Wallet section below.

The full 0.22.0 change log and list of direct contributors can be found on bitcoincore.org/en/releases/22.0/.

0.21.2 Release Notes

• On September 29, 2021, Bitcoin Core 0.21.2 was released and is now available from: bitcoincore.org/bin/bitcoin-core-0.21.2/
• This minor release includes various bug fixes and performance improvements, as well as updated translations.
• Bugs can be reported using the issue tracker at GitHub: github.com/bitcoin/bitcoin/issues
• To receive security and update notifications, subscribe to: bitcoincore.org/en/list/announcements/join/

How to Upgrade

If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes in some cases), then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux).

Upgrading directly from a version of Bitcoin Core that has reached its EOL is possible, but it might take some time if the data directory needs to be migrated. Old wallet versions of Bitcoin Core are generally supported.

Compatibility

Bitcoin Core is supported and extensively tested on operating systems using the Linux kernel, macOS 10.12+, and Windows 7 and newer. Bitcoin Core should also work on most other Unix-like systems but is not as frequently tested on them. It is not recommended to use Bitcoin Core on unsupported systems.

From Bitcoin Core 0.20.0 onwards, macOS versions earlier than 10.12 are no longer supported. Additionally, Bitcoin Core does not yet change appearance when macOS “dark mode” is activated.

The 0.21.2 change log and list of direct contributors can be found on bitcoincore.org/en/releases/0.21.2/.

Credits

• Photo from space courtesy of Nasa
• bitcoin.org: Running A Full Node