Inside Bitcoin

124.0.1 Release Notes
2====================
3
4Due to last-minute issues (#26616), 24.0, although tagged, was never fully
5announced or released.
6
7Bitcoin Core version 24.0.1 is now available from:
8
9  <https://bitcoincore.org/bin/bitcoin-core-24.0.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
22How to Upgrade
23==============
24
25If you are running an older version, shut it down. Wait until it has completely
26shut down (which might take a few minutes in some cases), then run the
27installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on macOS)
28or `bitcoind`/`bitcoin-qt` (on Linux).
29
30Upgrading directly from a version of Bitcoin Core that has reached its EOL is
31possible, but it might take some time if the data directory needs to be migrated. Old
32wallet versions of Bitcoin Core are generally supported.
33
34Compatibility
35==============
36
37Bitcoin Core is supported and extensively tested on operating systems
38using the Linux kernel, macOS 10.15+, and Windows 7 and newer.  Bitcoin
39Core should also work on most other Unix-like systems but is not as
40frequently tested on them.  It is not recommended to use Bitcoin Core on
41unsupported systems.
42
43Notice of new option for transaction replacement policies
44=========================================================
45
46This version of Bitcoin Core adds a new `mempoolfullrbf` configuration
47option which allows users to change the policy their individual node
48will use for relaying and mining unconfirmed transactions.  The option
49defaults to the same policy that was used in previous releases and no
50changes to node policy will occur if everyone uses the default.
51
52Some Bitcoin services today expect that the first version of an
53unconfirmed transaction that they see will be the version of the
54transaction that ultimately gets confirmed---a transaction acceptance
55policy sometimes called "first-seen".
56
57The Bitcoin Protocol does not, and cannot, provide any assurance that
58the first version of an unconfirmed transaction seen by a particular
59node will be the version that gets confirmed.  If there are multiple
60versions of the same unconfirmed transaction available, only the miner
61who includes one of those transactions in a block gets to decide which
62version of the transaction gets confirmed.
63
64Despite this lack of assurance, multiple merchants and services today
65still make this assumption.
66
67There are several benefits to users from removing this *first-seen*
68simplification.  One key benefit, the ability for the sender of a
69transaction to replace it with an alternative version paying higher
70fees, was realized in [Bitcoin Core 0.12.0][] (February 2016) with the
71introduction of [BIP125][] opt-in Replace By Fee (RBF).
72
73Since then, there has been discussion about completely removing the
74first-seen simplification and allowing users to replace any of their
75older unconfirmed transactions with newer transactions, a feature called
76*full-RBF*.  This release includes a `mempoolfullrbf` configuration
77option that allows enabling full-RBF, although it defaults to off
78(allowing only opt-in RBF).
79
80Several alternative node implementations have already enabled full-RBF by
81default for years, and several contributors to Bitcoin Core are
82advocating for enabling full-RBF by default in a future version of
83Bitcoin Core.
84
85As more nodes that participate in relay and mining begin enabling
86full-RBF, replacement of unconfirmed transactions by ones offering higher
87fees may rapidly become more reliable.
88
89Contributors to this project strongly recommend that merchants and services
90not accept unconfirmed transactions as final, and if they insist on doing so,
91to take the appropriate steps to ensure they have some recourse or plan for
92when their assumptions do not hold.
93
94[Bitcoin Core 0.12.0]: https://bitcoincore.org/en/releases/0.12.0/#opt-in-replace-by-fee-transactions
95[bip125]: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki
96
97Notable changes
98===============
99
100P2P and network changes
101-----------------------
102
103- To address a potential denial-of-service, the logic to download headers from peers
104  has been reworked.  This is particularly relevant for nodes starting up for the
105  first time (or for nodes which are starting up after being offline for a long time).
106
107  Whenever headers are received from a peer that have a total chainwork that is either
108  less than the node's `-minimumchainwork` value or is sufficiently below the work at
109  the node's tip, a "presync" phase will begin, in which the node will download the
110  peer's headers and verify the cumulative work on the peer's chain, prior to storing
111  those headers permanently. Once that cumulative work is verified to be sufficiently high,
112  the headers will be redownloaded from that peer and fully validated and stored.
113
114  This may result in initial headers sync taking longer for new nodes starting up for
115  the first time, both because the headers will be downloaded twice, and because the effect
116  of a peer disconnecting during the presync phase (or while the node's best headers chain has less
117  than `-minimumchainwork`), will result in the node needing to use the headers presync mechanism
118  with the next peer as well (downloading the headers twice, again). (#25717)
119
120- With I2P connections, a new, transient address is used for each outbound
121  connection if `-i2pacceptincoming=0`. (#25355)
122
123Updated RPCs
124------------
125
126- The `-deprecatedrpc=softforks` configuration option has been removed.  The
127  RPC `getblockchaininfo` no longer returns the `softforks` field, which was
128  previously deprecated in 23.0. (#23508) Information on soft fork status is
129  now only available via the `getdeploymentinfo` RPC.
130
131- The `deprecatedrpc=exclude_coinbase` configuration option has been removed.
132  The `receivedby` RPCs (`listreceivedbyaddress`, `listreceivedbylabel`,
133  `getreceivedbyaddress` and `getreceivedbylabel`) now always return results
134  accounting for received coins from coinbase outputs, without an option to
135  change that behaviour. Excluding coinbases was previously deprecated in 23.0.
136  (#25171)
137
138- The `deprecatedrpc=fees` configuration option has been removed. The top-level
139  fee fields `fee`, `modifiedfee`, `ancestorfees` and `descendantfees` are no
140  longer returned by RPCs `getmempoolentry`, `getrawmempool(verbose=true)`,
141  `getmempoolancestors(verbose=true)` and `getmempooldescendants(verbose=true)`.
142  The same fee fields can be accessed through the `fees` object in the result.
143  The top-level fee fields were previously deprecated in 23.0. (#25204)
144
145- The `getpeerinfo` RPC has been updated with a new `presynced_headers` field,
146  indicating the progress on the presync phase mentioned in the
147  "P2P and network changes" section above.
148
149Changes to wallet related RPCs can be found in the Wallet section below.
150
151New RPCs
152--------
153
154- The `sendall` RPC spends specific UTXOs to one or more recipients
155  without creating change. By default, the `sendall` RPC will spend
156  every UTXO in the wallet. `sendall` is useful to empty wallets or to
157  create a changeless payment from select UTXOs. When creating a payment
158  from a specific amount for which the recipient incurs the transaction
159  fee, continue to use the `subtractfeefromamount` option via the
160  `send`, `sendtoaddress`, or `sendmany` RPCs. (#24118)
161
162- A new `gettxspendingprevout` RPC has been added, which scans the mempool to find
163  transactions spending any of the given outpoints. (#24408)
164
165- The `simulaterawtransaction` RPC iterates over the inputs and outputs of the given
166  transactions, and tallies up the balance change for the given wallet. This can be
167  useful e.g. when verifying that a coin join like transaction doesn't contain unexpected
168  inputs that the wallet will then sign for unintentionally. (#22751)
169
170Updated REST APIs
171-----------------
172
173- The `/headers/` and `/blockfilterheaders/` endpoints have been updated to use
174  a query parameter instead of path parameter to specify the result count. The
175  count parameter is now optional, and defaults to 5 for both endpoints. The old
176  endpoints are still functional, and have no documented behaviour change.
177
178  For `/headers`, use
179  `GET /rest/headers/<BLOCK-HASH>.<bin|hex|json>?count=<COUNT=5>`
180  instead of
181  `GET /rest/headers/<COUNT>/<BLOCK-HASH>.<bin|hex|json>` (deprecated)
182
183  For `/blockfilterheaders/`, use
184  `GET /rest/blockfilterheaders/<FILTERTYPE>/<BLOCK-HASH>.<bin|hex|json>?count=<COUNT=5>`
185  instead of
186  `GET /rest/blockfilterheaders/<FILTERTYPE>/<COUNT>/<BLOCK-HASH>.<bin|hex|json>` (deprecated)
187
188  (#24098)
189
190Build System
191------------
192
193- Guix builds are now reproducible across architectures (x86_64 & aarch64). (#21194)
194
195New settings
196------------
197
198- A new `mempoolfullrbf` option has been added, which enables the mempool to
199  accept transaction replacement without enforcing BIP125 replaceability
200  signaling. (#25353)
201
202Wallet
203------
204
205- The `-walletrbf` startup option will now default to `true`. The
206  wallet will now default to opt-in RBF on transactions that it creates. (#25610)
207
208- The `replaceable` option for the `createrawtransaction` and
209  `createpsbt` RPCs will now default to `true`. Transactions created
210  with these RPCs will default to having opt-in RBF enabled. (#25610)
211
212- The `wsh()` output descriptor was extended with Miniscript support. You can import Miniscript
213  descriptors for P2WSH in a watchonly wallet to track coins, but you can't spend from them using
214  the Bitcoin Core wallet yet.
215  You can find more about Miniscript on the [reference website](https://bitcoin.sipa.be/miniscript/). (#24148)
216
217- The `tr()` output descriptor now supports multisig scripts through the `multi_a()` and
218  `sortedmulti_a()` functions. (#24043)
219
220- To help prevent fingerprinting transactions created by the Bitcoin Core wallet, change output
221  amounts are now randomized. (#24494)
222
223- The `listtransactions`, `gettransaction`, and `listsinceblock`
224  RPC methods now include a wtxid field (hash of serialized transaction,
225  including witness data) for each transaction. (#24198)
226
227- The `listsinceblock`, `listtransactions` and `gettransaction` output now contain a new
228  `parent_descs` field for every "receive" entry. (#25504)
229
230- A new optional `include_change` parameter was added to the `listsinceblock` command.
231
232- RPC `getreceivedbylabel` now returns an error, "Label not found
233  in wallet" (-4), if the label is not in the address book. (#25122)
234
235Migrating Legacy Wallets to Descriptor Wallets
236---------------------------------------------
237
238An experimental RPC `migratewallet` has been added to migrate Legacy (non-descriptor) wallets to
239Descriptor wallets. More information about the migration process is available in the
240[documentation](https://github.com/bitcoin/bitcoin/blob/master/doc/managing-wallets.md#migrating-legacy-wallets-to-descriptor-wallets).
241
242GUI changes
243-----------
244
245- A new menu item to restore a wallet from a backup file has been added (gui#471).
246
247- Configuration changes made in the bitcoin GUI (such as the pruning setting,
248proxy settings, UPNP preferences) are now saved to `<datadir>/settings.json`
249file rather than to the Qt settings backend (windows registry or unix desktop
250config files), so these settings will now apply to bitcoind, instead of being