bitcoin/doc/release-notes.md

After branching off for a major version release of Bitcoin Core, use this template to create the initial release notes draft.

The release notes draft is a temporary file that can be added to by anyone. See /doc/developer-notes.md#release-notes for the process.

Create the draft, named "version Release Notes Draft" (e.g. "0.20.0 Release Notes Draft"), as a collaborative wiki in:

https://github.com/bitcoin-core/bitcoin-devwiki/wiki/

Before the final release, move the notes back to this git repository.

version Release Notes Draft

Bitcoin Core version version is now available from:

https://bitcoincore.org/bin/bitcoin-core-*version*/

This release includes new features, various bug fixes and performance improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

https://github.com/bitcoin/bitcoin/issues

To receive security and update notifications, please subscribe to:

https://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.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 NAT-PMP port mapping support via libnatpmp. (#18077)

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 (e.g. 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)

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

New RPCs

Build System

New settings

• The -natpmp option has been added to use NAT-PMP to map the listening port. If both UPnP and NAT-PMP are enabled, a successful allocation from UPnP prevails over one from NAT-PMP. (#18077)

Updated settings

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

• Passing an invalid -rpcauth argument now cause bitcoind to fail to start. (#20461)

• The getnodeaddresses RPC now returns a "network" field indicating the network type (ipv4, ipv6, onion, or i2p) for each address. (#21594)

Tools and Utilities

Wallet

• A new listdescriptors RPC is available to inspect the contents of descriptor-enabled wallets. The RPC returns public versions of all imported descriptors, including their timestamp and flags. For ranged descriptors, it also returns the range boundaries and the next index to generate addresses from. (#20226)

• The bumpfee RPC is not available with wallets that have private keys disabled. psbtbumpfee can be used instead. (#20891)

GUI changes

Low-level changes

RPC

• The RPC server can process a limited number of simultaneous RPC requests. Previously, if this limit was exceeded, the RPC server would respond with status code 500 (HTTP_INTERNAL_SERVER_ERROR). Now it returns status code 503 (HTTP_SERVICE_UNAVAILABLE). (#18335)

• Error codes have been updated to be more accurate for the following error cases (#18466):

  • signmessage now returns RPC_INVALID_ADDRESS_OR_KEY (-5) if the passed address is invalid. Previously returned RPC_TYPE_ERROR (-3).
  • verifymessage now returns RPC_INVALID_ADDRESS_OR_KEY (-5) if the passed address is invalid. Previously returned RPC_TYPE_ERROR (-3).
  • verifymessage now returns RPC_TYPE_ERROR (-3) if the passed signature is malformed. Previously returned RPC_INVALID_ADDRESS_OR_KEY (-5).

Tests

Credits

Thanks to everyone who directly contributed to this release:

As well as to everyone that helped with translations on Transifex.