release-notes-22.0.md raw

22.0 Release Notes ==================

Bitcoin Core version 22.0 is now available from:

<https://bitcoincore.org/bin/bitcoin-core-22.0/>

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

I2P (Invisible Internet Project) service and connect to such services. See i2p.md for details. (#20685)

v3 only, as the Tor network [dropped support for Tor v2](https://blog.torproject.org/v2-deprecation-timeline) 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)

`libnatpmp`. (#18077)

New and Updated RPCs

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)

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)

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)

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)

with the -json option set, the following fields: addresses, reqSigs are no longer returned in the tx output of the response. (#20286)

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)

network type (ipv4, ipv6, onion, or i2p) for each address. (#21594)

or i2p) to return only addresses of the specified network. (#21843)

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)

Segwit addresses. (#20867)

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

Build System

The /doc/release-process.md document has been updated accordingly.

Files

in JSON format in banlist.json instead of banlist.dat. banlist.dat is only read on startup if banlist.json is not present. Changes are only written to the new banlist.json. A future version of Bitcoin Core may completely ignore banlist.dat. (#20966)

New settings

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.

Tools and Utilities

node per network type (including Tor v2 versus v3) and total. This can be useful to see if the node knows enough addresses in a network to use options like -onlynet=<network> or to upgrade to this release of Bitcoin Core 22.0 that supports Tor v3 only. (#21595)

in seconds to use with -rpcwait. If the timeout expires, bitcoin-cli will report a failure. (#21056)

Wallet

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)

disabled. psbtbumpfee can be used instead. (#20891)

that when true allows using unsafe inputs to fund the transaction. Note that the resulting transaction may become invalid if one of the unsafe inputs disappears. If that happens, the transaction must be funded with different inputs and republished. (#21359)

under wsh(). (#20867)

GUI changes

Low-level changes =================

RPC

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)

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

Tests

22.0 change log ===============

A detailed list of changes in this version follows. To keep the list to a manageable length, small refactors and typo fixes are not included, and similar changes are sometimes condensed into one line.

Consensus

Policy

Mining

Block and transaction handling

P2P protocol and network code

Wallet

RPC and other APIs

GUI

Build system

Tests and QA

Miscellaneous

Documentation

Credits =======

Thanks to everyone who directly contributed to this release:

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