Inside Bitcoin

122.0 Release Notes
2==================
3
4Bitcoin Core version 22.0 is now available from:
5
6  <https://bitcoincore.org/bin/bitcoin-core-22.0/>
7
8This release includes new features, various bug fixes and performance
9improvements, as well as updated translations.
10
11Please report bugs using the issue tracker at GitHub:
12
13  <https://github.com/bitcoin/bitcoin/issues>
14
15To receive security and update notifications, please subscribe to:
16
17  <https://bitcoincore.org/en/list/announcements/join/>
18
19How to Upgrade
20==============
21
22If you are running an older version, shut it down. Wait until it has completely
23shut down (which might take a few minutes in some cases), then run the
24installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
25or `bitcoind`/`bitcoin-qt` (on Linux).
26
27Upgrading directly from a version of Bitcoin Core that has reached its EOL is
28possible, but it might take some time if the data directory needs to be migrated. Old
29wallet versions of Bitcoin Core are generally supported.
30
31Compatibility
32==============
33
34Bitcoin Core is supported and extensively tested on operating systems
35using the Linux kernel, macOS 10.14+, and Windows 7 and newer.  Bitcoin
36Core should also work on most other Unix-like systems but is not as
37frequently tested on them.  It is not recommended to use Bitcoin Core on
38unsupported systems.
39
40From Bitcoin Core 22.0 onwards, macOS versions earlier than 10.14 are no longer supported.
41
42Notable changes
43===============
44
45P2P and network changes
46-----------------------
47- Added support for running Bitcoin Core as an
48  [I2P (Invisible Internet Project)](https://en.wikipedia.org/wiki/I2P) service
49  and connect to such services. See [i2p.md](https://github.com/bitcoin/bitcoin/blob/22.x/doc/i2p.md) for details. (#20685)
50- This release removes support for Tor version 2 hidden services in favor of Tor
51  v3 only, as the Tor network [dropped support for Tor
52  v2](https://blog.torproject.org/v2-deprecation-timeline) with the release of
53  Tor version 0.4.6.  Henceforth, Bitcoin Core ignores Tor v2 addresses; it
54  neither rumors them over the network to other peers, nor stores them in memory
55  or to `peers.dat`.  (#22050)
56
57- Added NAT-PMP port mapping support via
58  [`libnatpmp`](https://miniupnp.tuxfamily.org/libnatpmp.html). (#18077)
59
60New and Updated RPCs
61--------------------
62
63- Due to [BIP 350](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki)
64  being implemented, behavior for all RPCs that accept addresses is changed when
65  a native witness version 1 (or higher) is passed. These now require a Bech32m
66  encoding instead of a Bech32 one, and Bech32m encoding will be used for such
67  addresses in RPC output as well. No version 1 addresses should be created
68  for mainnet until consensus rules are adopted that give them meaning
69  (as will happen through [BIP 341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki)).
70  Once that happens, Bech32m is expected to be used for them, so this shouldn't
71  affect any production systems, but may be observed on other networks where such
72  addresses already have meaning (like signet). (#20861)
73
74- The `getpeerinfo` RPC returns two new boolean fields, `bip152_hb_to` and
75  `bip152_hb_from`, that respectively indicate whether we selected a peer to be
76  in compact blocks high-bandwidth mode or whether a peer selected us as a
77  compact blocks high-bandwidth peer. High-bandwidth peers send new block
78  announcements via a `cmpctblock` message rather than the usual inv/headers
79  announcements. See BIP 152 for more details. (#19776)
80
81- `getpeerinfo` no longer returns the following fields: `addnode`, `banscore`,
82  and `whitelisted`, which were previously deprecated in 0.21. Instead of
83  `addnode`, the `connection_type` field returns manual. Instead of
84  `whitelisted`, the `permissions` field indicates if the peer has special
85  privileges. The `banscore` field has simply been removed. (#20755)
86
87- The following RPCs:  `gettxout`, `getrawtransaction`, `decoderawtransaction`,
88  `decodescript`, `gettransaction`, and REST endpoints: `/rest/tx`,
89  `/rest/getutxos`, `/rest/block` deprecated the following fields (which are no
90  longer returned in the responses by default): `addresses`, `reqSigs`.
91  The `-deprecatedrpc=addresses` flag must be passed for these fields to be
92  included in the RPC response. This flag/option will be available only for this major release, after which
93  the deprecation will be removed entirely. Note that these fields are attributes of
94  the `scriptPubKey` object returned in the RPC response. However, in the response
95  of `decodescript` these fields are top-level attributes, and included again as attributes
96  of the `scriptPubKey` object. (#20286)
97
98- When creating a hex-encoded bitcoin transaction using the `bitcoin-tx` utility
99  with the `-json` option set, the following fields: `addresses`, `reqSigs` are no longer
100  returned in the tx output of the response. (#20286)
101
102- The `listbanned` RPC now returns two new numeric fields: `ban_duration` and `time_remaining`.
103  Respectively, these new fields indicate the duration of a ban and the time remaining until a ban expires,
104  both in seconds. Additionally, the `ban_created` field is repositioned to come before `banned_until`. (#21602)
105
106- The `setban` RPC can ban onion addresses again. This fixes a regression introduced in version 0.21.0. (#20852)
107
108- The `getnodeaddresses` RPC now returns a "network" field indicating the
109  network type (ipv4, ipv6, onion, or i2p) for each address.  (#21594)
110
111- `getnodeaddresses` now also accepts a "network" argument (ipv4, ipv6, onion,
112  or i2p) to return only addresses of the specified network.  (#21843)
113
114- The `testmempoolaccept` RPC now accepts multiple transactions (still experimental at the moment,
115  API may be unstable). This is intended for testing transaction packages with dependency
116  relationships; it is not recommended for batch-validating independent transactions. In addition to
117  mempool policy, package policies apply: the list cannot contain more than 25 transactions or have a
118  total size exceeding 101K virtual bytes, and cannot conflict with (spend the same inputs as) each other or
119  the mempool, even if it would be a valid BIP125 replace-by-fee. There are some known limitations to
120  the accuracy of the test accept: it's possible for `testmempoolaccept` to return "allowed"=True for a
121  group of transactions, but "too-long-mempool-chain" if they are actually submitted. (#20833)
122
123- `addmultisigaddress` and `createmultisig` now support up to 20 keys for
124  Segwit addresses. (#20867)
125
126Changes to Wallet or GUI related RPCs can be found in the GUI or Wallet section below.
127
128Build System
129------------
130
131- Release binaries are now produced using the new `guix`-based build system.
132  The [/doc/release-process.md](/doc/release-process.md) document has been updated accordingly.
133
134Files
135-----
136
137- The list of banned hosts and networks (via `setban` RPC) is now saved on disk
138  in JSON format in `banlist.json` instead of `banlist.dat`. `banlist.dat` is
139  only read on startup if `banlist.json` is not present. Changes are only written to the new
140  `banlist.json`. A future version of Bitcoin Core may completely ignore
141  `banlist.dat`. (#20966)
142
143New settings
144------------
145
146- The `-natpmp` option has been added to use NAT-PMP to map the listening port.
147  If both UPnP and NAT-PMP are enabled, a successful allocation from UPnP
148  prevails over one from NAT-PMP. (#18077)
149
150Updated settings
151----------------
152
153Changes to Wallet or GUI related settings can be found in the GUI or Wallet section below.
154
155- Passing an invalid `-rpcauth` argument now cause bitcoind to fail to start.  (#20461)
156
157Tools and Utilities
158-------------------
159
160- A new CLI `-addrinfo` command returns the number of addresses known to the
161  node per network type (including Tor v2 versus v3) and total. This can be
162  useful to see if the node knows enough addresses in a network to use options
163  like `-onlynet=<network>` or to upgrade to this release of Bitcoin Core 22.0
164  that supports Tor v3 only.  (#21595)
165
166- A new `-rpcwaittimeout` argument to `bitcoin-cli` sets the timeout
167  in seconds to use with `-rpcwait`. If the timeout expires,
168  `bitcoin-cli` will report a failure. (#21056)
169
170Wallet
171------
172
173- External signers such as hardware wallets can now be used through the new RPC methods `enumeratesigners` and `displayaddress`. Support is also added to the `send` RPC call. This feature is experimental. See [external-signer.md](https://github.com/bitcoin/bitcoin/blob/22.x/doc/external-signer.md) for details. (#16546)
174
175- A new `listdescriptors` RPC is available to inspect the contents of descriptor-enabled wallets.
176  The RPC returns public versions of all imported descriptors, including their timestamp and flags.
177  For ranged descriptors, it also returns the range boundaries and the next index to generate addresses from. (#20226)
178
179- The `bumpfee` RPC is not available with wallets that have private keys
180  disabled. `psbtbumpfee` can be used instead. (#20891)
181
182- The `fundrawtransaction`, `send` and `walletcreatefundedpsbt` RPCs now support an `include_unsafe` option
183  that when `true` allows using unsafe inputs to fund the transaction.
184  Note that the resulting transaction may become invalid if one of the unsafe inputs disappears.
185  If that happens, the transaction must be funded with different inputs and republished. (#21359)
186
187- We now support up to 20 keys in `multi()` and `sortedmulti()` descriptors
188  under `wsh()`. (#20867)
189
190- Taproot descriptors can be imported into the wallet only after activation has occurred on the network (e.g. mainnet, testnet, signet) in use. See [descriptors.md](https://github.com/bitcoin/bitcoin/blob/22.x/doc/descriptors.md) for supported descriptors.
191
192GUI changes
193-----------
194
195- External signers such as hardware wallets can now be used. These require an external tool such as [HWI](https://github.com/bitcoin-core/HWI) to be installed and configured under Options -> Wallet. When creating a new wallet a new option "External signer" will appear in the dialog. If the device is detected, its name is suggested as the wallet name. The watch-only keys are then automatically imported. Receive addresses can be verified on the device. The send dialog will automatically use the connected device. This feature is experimental and the UI may freeze for a few seconds when performing these actions.
196
197Low-level changes
198=================
199
200RPC
201---
202
203- The RPC server can process a limited number of simultaneous RPC requests.
204  Previously, if this limit was exceeded, the RPC server would respond with
205  [status code 500 (`HTTP_INTERNAL_SERVER_ERROR`)](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#5xx_server_errors).
206  Now it returns status code 503 (`HTTP_SERVICE_UNAVAILABLE`). (#18335)
207
208- Error codes have been updated to be more accurate for the following error cases (#18466):
209  - `signmessage` now returns RPC_INVALID_ADDRESS_OR_KEY (-5) if the
210    passed address is invalid. Previously returned RPC_TYPE_ERROR (-3).
211  - `verifymessage` now returns RPC_INVALID_ADDRESS_OR_KEY (-5) if the
212    passed address is invalid. Previously returned RPC_TYPE_ERROR (-3).
213  - `verifymessage` now returns RPC_TYPE_ERROR (-3) if the passed signature
214    is malformed. Previously returned RPC_INVALID_ADDRESS_OR_KEY (-5).
215
216Tests
217-----
218
21922.0 change log
220===============
221
222A 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.
223
224### Consensus
225- bitcoin/bitcoin#19438 Introduce deploymentstatus (ajtowns)
226- bitcoin/bitcoin#20207 Follow-up extra comments on taproot code and tests (sipa)
227- bitcoin/bitcoin#21330 Deal with missing data in signature hashes more consistently (sipa)
228
229### Policy
230- bitcoin/bitcoin#18766 Disable fee estimation in blocksonly mode (by removing the fee estimates global) (darosior)
231- bitcoin/bitcoin#20497 Add `MAX_STANDARD_SCRIPTSIG_SIZE` to policy (sanket1729)
232- bitcoin/bitcoin#20611 Move `TX_MAX_STANDARD_VERSION` to policy (MarcoFalke)
233
234### Mining
235- bitcoin/bitcoin#19937, bitcoin/bitcoin#20923 Signet mining utility (ajtowns)
236
237### Block and transaction handling
238- bitcoin/bitcoin#14501 Fix possible data race when committing block files (luke-jr)
239- bitcoin/bitcoin#15946 Allow maintaining the blockfilterindex when using prune (jonasschnelli)
240- bitcoin/bitcoin#18710 Add local thread pool to CCheckQueue (hebasto)
241- bitcoin/bitcoin#19521 Coinstats Index (fjahr)
242- bitcoin/bitcoin#19806 UTXO snapshot activation (jamesob)
243- bitcoin/bitcoin#19905 Remove dead CheckForkWarningConditionsOnNewFork (MarcoFalke)
244- bitcoin/bitcoin#19935 Move SaltedHashers to separate file and add some new ones (achow101)
245- bitcoin/bitcoin#20054 Remove confusing and useless "unexpected version" warning (MarcoFalke)
246- bitcoin/bitcoin#20519 Handle rename failure in `DumpMempool(…)` by using the `RenameOver(…)` return value (practicalswift)
247- bitcoin/bitcoin#20749, bitcoin/bitcoin#20750, bitcoin/bitcoin#21055, bitcoin/bitcoin#21270, bitcoin/bitcoin#21525, bitcoin/bitcoin#21391, bitcoin/bitcoin#21767, bitcoin/bitcoin#21866 Prune `g_chainman` usage (dongcarl)
248- bitcoin/bitcoin#20833 rpc/validation: enable packages through testmempoolaccept (glozow)
249- bitcoin/bitcoin#20834 Locks and docs in ATMP and CheckInputsFromMempoolAndCache (glozow)
250- bitcoin/bitcoin#20854 Remove unnecessary try-block (amitiuttarwar)