1v32.1 Release Notes
2===================
3
4Due to last-minute issues, 32.0, although tagged, was never
5fully announced or released.
6
7Bitcoin Core version 32.1 is now available from:
8
9  <https://bitcoincore.org/bin/bitcoin-core-32.1/>
10
11This release includes new features, various bug fixes and performance
12improvements, as well as updated translations.
13
14Please report bugs using the issue tracker at GitHub:
15
16  <https://github.com/bitcoin/bitcoin/issues>
17
18To receive security and update notifications, please subscribe to:
19
20  <https://bitcoincore.org/en/list/announcements/join/>
21
22With the release of this new major version, versions 29.x and
23older are at "End of Life" and will no longer receive updates.
24
25In accordance with the security policy, we will in two weeks disclose:
26
27* Medium and high severity vulnerabilities fixed in 30.0. There are 3 of these.
28
29* Low severity vulnerabilities fixed in 32.1. There are 0 of these.
30
31How to Upgrade
32==============
33
34If you are running an older version, shut it down. Wait until it has completely
35shut down (which might take a few minutes in some cases), then run the
36installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on macOS)
37or `bin/` and `libexec/` (on Linux).
38
39Upgrading directly from a version of Bitcoin Core that has reached its EOL is
40possible, but it might take some time if the data directory needs to be migrated. Old
41wallet versions of Bitcoin Core are generally supported.
42
43Compatibility
44==============
45
46Bitcoin Core is supported and tested on the following operating systems or newer:
47Linux Kernel 3.17, macOS 14, and Windows 10 (version 1903). Bitcoin
48Core should also work on most other Unix-like systems but is not as
49frequently tested on them. It is not recommended to use Bitcoin Core on
50unsupported systems.
51
52Notable changes
53===============
54
55P2P and network changes
56-----------------------
57
58- Tor hidden services that are created automatically by Bitcoin Core will have
59  [PoW defenses](https://tpo.pages.torproject.net/onion-services/ecosystem/technology/security/pow/)
60  enabled if the Tor daemon supports that. (#33414)
61- To reduce memory and CPU usage during periods of high transaction volume,
62  rate-limiting of outgoing transaction relay has been changed to use a global
63  backlog instead of being done on a per-peer basis. The default rate-limit
64  remains as 14 tx/s (boosted by 2.5x for outbound peers), though this can be
65  changed via the `-txsendrate` configuration option. An additional bandwidth
66  rate-limit has also been introduced at 12MB of transactions per 10 minutes,
67  with a high burst rate. The size of the global backlog and the token bucket
68  values for the rate limits can be queried via the `getnetworkinfo` RPC.
69  (#34628)
70- Fix a possible leak of the originator's IP address for transactions sent with
71  `sendrawtransaction` RPC when `-privatebroadcast=1`. When Bitcoin Core
72  connects to a peer, if that peer has been advertised to support P2P protocol
73  v2, then Bitcoin Core tries to use the v2 protocol and if that fails it
74  retries the connection using the v1 protocol. When the private broadcast is
75  about to send a transaction to an IPv4 or IPv6 peer it overrides the normal
76  proxy selection and forces the connection through the Tor proxy (and thus
77  through the Tor network, protecting the sender's IP address). However if v2
78  protocol is tried and it fails, then the v1 retry connection would be made
79  disregarding the "override proxy" request, possibly making an IPv4 or IPv6
80  direct connection. In other words, for this to happen the following must be
81  true:
82  1. An IPv4 or IPv6 address has been advertised to the sender, indicating v2
83     support.
84  2. The sender must have Tor configured.
85  3. The sender's configuration must be such that connections to IPv4 or IPv6
86     are made directly (no `-proxy=` is used for IPv4 or IPv6).
87  4. The recipient does not support v2 (the flags from 1. are bogus). (#35410)
88- The private-broadcast queue (transactions submitted via `sendrawtransaction`
89  when `-privatebroadcast` is enabled and not yet echoed back from the network)
90  is now capped at 10,000 entries. When full, new submissions are rejected. It
91  is up to the caller to inspect the queue via `getprivatebroadcastinfo` and
92  free up space when stuck via `abortprivatebroadcast`. (#35406)
93- Each transaction sent via private broadcast (`-privatebroadcast`) is limited
94  to 1,000 send attempts. After reaching the limit, broadcasting stops; call
95  `sendrawtransaction` again to retry. Transactions that reach the limit remain
96  available through `getprivatebroadcastinfo` and `abortprivatebroadcast`.
97  (#35680)
98- Support for the legacy ElGamal (type 0) encryption type when creating I2P
99  sessions is being sunset by the I2P network and will be removed from bitcoind
100  on or before v34. Nodes using I2P with versions of Bitcoin Core earlier than
101  v26.1 (PRs #29200, #29209) will soon only be able to connect to other legacy
102  ElGamal I2P peers and will be increasingly isolated from the rest of the
103  network, with a reduced anonymity set. See #35696 for details. (#35696)
104- The project is currently considering whether to drop support for CJDNS (see
105  discussion in #36041). Since its introduction in v23.0, it has not gained
106  substantial adoption amongst nodes, and there is some concern about supporting
107  a network with such a low number of peers. (#36202)
108- The CJDNS documentation was updated in #34811 to simplify the setup / peer
109  discovery process. (#36202)
110- The default maximum number of automatic peer connections (`-maxconnections`)
111  has increased from 125 to 200, providing additional inbound capacity for
112  block-relay-only peers. By default, transaction-relaying peers may use at most
113  50% of inbound connection slots. This percentage can be configured with the
114  new `-inboundrelaypercent` option, which accepts values from 0 to 100 and
115  defaults to 50. The number of automatic outbound connections is unchanged.
116  (#28463)
117- Explicitly configured `-maxconnections` values remain unchanged, but the new
118  inbound transaction-relay limit still applies. To retain the previous
119  connection limits, use `-maxconnections=125 -inboundrelaypercent=100`.
120`-maxconnections` now clamps values above 2,000 with a warning to reduce
121  crash risk at very high peer counts. (#35919)
122
123Mempool
124-------
125
126- mempoolfullrbf=1 behaviour has been the default since v28 and the argument has
127  been removed since v29 subsequently. The `getmempoolinfo` RPC stops returning
128  the deprecated `fullrbf` key in the response unless the user requests it via
129  the `-deprecatedrpc=fullrbf` node argument. Also, the `bip125-replaceable` key
130  is removed from the mempool RPCs responses (because it, too, has been
131  deprecated since v29) unless the user requests it via `-deprecatedrpc=bip125`
132  node argument. Affected mempool RPCs are `getrawmempool`,
133  `getmempoolancestors`, `getmempooldescendants`, and `getmempoolentry`.
134  (#34911)
135
136Updated RPCs
137------------
138
139- `createpsbt`, `walletcreatefundedpsbt`, `converttopsbt`, and `psbtbumpfee`
140  will now default to creating version 2 PSBTs. An optional `psbt_version`
141  argument is added to these RPCs which allows specifying the version of PSBT to
142  create. (#21283)
143- 'taproot' has been removed from 'getdeploymentinfo' because its historical
144  activation height is no longer used anywhere in the codebase. Applications
145  that rely on `deployments.taproot` to detect Taproot support should either
146  assume Taproot to be always active (since Bitcoin Core v24.0), or check for
147  `TAPROOT` in the `script_flags` array returned by `getdeploymentinfo` (since
148  Bitcoin Core v31.0). (#26201)
149- Bitcoin Core now reports a debug message explaining why transaction inputs are
150  non-standard. This information is now returned in the responses of the
151  transaction-sending RPCs `submitpackage`, `sendrawtransaction`, and
152  `testmempoolaccept`, and is also logged to `debug.log` (if `mempoolrej` +
153  debug category is enabled) when such transactions are received over the P2P
154  network. This does not change the existing error code
155  `bad-txns-nonstandard-inputs`, but instead adds additional debug information
156  to it. (#29060)
157- The `dumptxoutset` RPC now supports writing to a named pipe on UNIX-like
158  systems (see mkfifo(1) and mkfifo(3) man pages). This allows the raw UTXO set
159  data to be consumed directly by another process (e.g., the
160  `contrib/utxo-tools/utxo_to_sqlite.py` conversion script) without first
161  writing it to disk. (#31560)
162- Mempool RPCs (`getrawmempool`, `getmempoolentry`, `testmempoolaccept`,
163  `submitpackage`) now include an additional field `vsize_adjusted` (which is
164  the sigop-adjusted virtual size used for policy) and `vsize_bip141` (which
165  represents the raw BIP141 virtual size). While `vsize` is marked as
166  DEPRECATED, it was previously erroneously described as the BIP 141 vsize, but
167  is actually sigops-adjusted vsize. Use `vsize_bip141` to actually get that
168  behavior or switch to the explicit `vsize_adjusted` for retained behavior.
169  (#32800)
170- `getrawtransaction` RPC now includes an additional field `vsize_adjusted`,
171  which is the sigop-adjusted virtual size if the transaction is in the mempool.
172  (#32800)
173- The `getblockchaininfo` RPC now exposes progress for background validation if
174  the `assumeutxo` feature is used. Once a node has synced from snapshot to tip,
175  `verificationprogress` returns 1.0 and `initialblockdownload` false even
176  though the node may still be validating blocks in the background. A new
177  object, `backgroundvalidation`, provides details about the snapshot being
178  validated, including snapshot height, number of blocks processed, best block
179  hash, chainwork, median time, and verification progress. (#33259)
180- `getbalances` now includes a `nonmempool` field under `mine`, reporting the
181  net balance of wallet transactions that are not in the mempool (e.g. due to
182  too low a feerate, too many unconfirmed ancestors, or a too-large `OP_RETURN`
183  output). This value is always negative, and is typically an over-estimate
184  since it accounts for coins being spent but not for change outputs returning
185  to the wallet (which are also outside the mempool). Without this field, funds
186  involved in non-mempool transactions could appear to go missing from the
187  wallet balance. (#33671)
188- The `estimatesmartfee` RPC now combines two fee rate estimators: the existing
189  block policy fee rate estimator and a new mempool fee rate estimator. (#34075)
190- The new mempool fee rate estimator produces conservative and economical fee
191  rate estimates from the current contents of the mempool. It only produces a
192  fee rate estimate when recent blocks indicate a healthy mempool, and falls
193  back to the higher of the minimum relay fee rate and the current mempool
194  minimum fee rate when the mempool is too sparse. Its statistics are persisted
195  to `fees/mempool_policy_estimator.dat` and reloaded on startup.
196  `estimatesmartfee` returns the lower of the two fee rate estimators' results,
197  so the mempool fee rate estimator can only lower the block policy fee rate
198  estimate. (#34075)
199- `estimatesmartfee` accepts an `options` object with `fee_rate_estimator`.
200  Recognized values are `"auto"` (the default, combined behavior described
201  above), `"block_policy"` (use only the block policy fee rate estimator), and
202  `"mempool_policy"` (use only the mempool fee rate estimator). All unknown
203  values are rejected. Users who want the previous behavior can
204  select the block policy fee rate estimator explicitly. (#34075)
205- The options object also accepts `verbosity`. A verbosity of `2` or higher also
206  returns `mempool_health_statistics`. (#34075)
207- When `fee_rate_estimator` is `"auto"` and the estimate succeeds, the response
208  also includes an `estimator` field identifying which fee rate estimator
209  produced the result. (#34075)
210- Block policy fee estimator data is now stored in
211  `fees/block_policy_estimates.dat`. If the new file does not exist, the legacy
212  `fee_estimates.dat` file is moved to the new path during startup. If both
213  files exist, the legacy file is removed. (#34075)
214- Wallet fee rate estimation uses the default combined estimate. (#34075)
215
216- The `-deprecatedrpc=startingheight` configuration option has been removed. The
217  `getpeerinfo` RPC no longer returns the `startingheight` field, which was
218  previously deprecated in v31.0. (#34796)
219- The `migratewallet` RPC now gives the option to not load the descriptor wallet
220  after migrating it from a legacy wallet. This will now allow pruned nodes to
221  migrate a wallet out of sync below the pruning height. Note that to use the
222  new wallet it must be loaded to a full node anyway. (#35266)
223- The `getprivatebroadcastinfo` and `abortprivatebroadcast` RPCs now return an
224  error `-32601`, "Method not found", when `-privatebroadcast` is not enabled at
225  startup. (#35267)
226- `gettransaction`, `listtransactions`, and `listsinceblock` now have an
227  `alternate_wtxids` field which lists the wtxids of all transactions that have
228  the same txid. When there is only one known witness variant the field is an
229  empty array, analogous to `walletconflicts` and `mempoolconflicts`. (#35501)
230- `getprivatebroadcastinfo` now reports an `attempts_remaining` field for each
231  transaction. (#35680)
232- `getnetworkinfo` now reports the `asmap_version` if `-asmap` is in use. The
233  version is the hash of the asmap data and can be verified against the hash of
234  the raw asmap data file that also gets attested in the
235  [asmap-data](https://github.com/bitcoin-core/asmap-data) repository with
236  `sha256sum`. (#36249)
237
238Changes to wallet related RPCs can be found in the Wallet section below.
239
240New RPCs
241--------
242
243- A new `exportasmap` RPC writes the ASMap data embedded at build time to a
244  file. (#33920)
245- A new `getopenrpcinfo` RPC returns a machine-readable OpenRPC 1.4.1
246  description of the RPCs available on the running node, including their
247  parameters and result schemas. The new `rpc.discover` method provides the same
248  public document using OpenRPC’s standard service discovery method. To include
249  hidden commands and arguments, call `getopenrpcinfo` with `show_hidden=true`.
250  (#34683)