/ doc / release-notes / release-notes-24.0.1.md
release-notes-24.0.1.md
  1  24.0.1 Release Notes
  2  ====================
  3  
  4  Due to last-minute issues (#26616), 24.0, although tagged, was never fully
  5  announced or released.
  6  
  7  Bitcoin Core version 24.0.1 is now available from:
  8  
  9    <https://bitcoincore.org/bin/bitcoin-core-24.0.1/>
 10  
 11  This release includes new features, various bug fixes and performance
 12  improvements, as well as updated translations.
 13  
 14  Please report bugs using the issue tracker at GitHub:
 15  
 16    <https://github.com/bitcoin/bitcoin/issues>
 17  
 18  To receive security and update notifications, please subscribe to:
 19  
 20    <https://bitcoincore.org/en/list/announcements/join/>
 21  
 22  How to Upgrade
 23  ==============
 24  
 25  If you are running an older version, shut it down. Wait until it has completely
 26  shut down (which might take a few minutes in some cases), then run the
 27  installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on macOS)
 28  or `bitcoind`/`bitcoin-qt` (on Linux).
 29  
 30  Upgrading directly from a version of Bitcoin Core that has reached its EOL is
 31  possible, but it might take some time if the data directory needs to be migrated. Old
 32  wallet versions of Bitcoin Core are generally supported.
 33  
 34  Compatibility
 35  ==============
 36  
 37  Bitcoin Core is supported and extensively tested on operating systems
 38  using the Linux kernel, macOS 10.15+, and Windows 7 and newer.  Bitcoin
 39  Core should also work on most other Unix-like systems but is not as
 40  frequently tested on them.  It is not recommended to use Bitcoin Core on
 41  unsupported systems.
 42  
 43  Notice of new option for transaction replacement policies
 44  =========================================================
 45  
 46  This version of Bitcoin Core adds a new `mempoolfullrbf` configuration
 47  option which allows users to change the policy their individual node
 48  will use for relaying and mining unconfirmed transactions.  The option
 49  defaults to the same policy that was used in previous releases and no
 50  changes to node policy will occur if everyone uses the default.
 51  
 52  Some Bitcoin services today expect that the first version of an
 53  unconfirmed transaction that they see will be the version of the
 54  transaction that ultimately gets confirmed---a transaction acceptance
 55  policy sometimes called "first-seen".
 56  
 57  The Bitcoin Protocol does not, and cannot, provide any assurance that
 58  the first version of an unconfirmed transaction seen by a particular
 59  node will be the version that gets confirmed.  If there are multiple
 60  versions of the same unconfirmed transaction available, only the miner
 61  who includes one of those transactions in a block gets to decide which
 62  version of the transaction gets confirmed.
 63  
 64  Despite this lack of assurance, multiple merchants and services today
 65  still make this assumption.
 66  
 67  There are several benefits to users from removing this *first-seen*
 68  simplification.  One key benefit, the ability for the sender of a
 69  transaction to replace it with an alternative version paying higher
 70  fees, was realized in [Bitcoin Core 0.12.0][] (February 2016) with the
 71  introduction of [BIP125][] opt-in Replace By Fee (RBF).
 72  
 73  Since then, there has been discussion about completely removing the
 74  first-seen simplification and allowing users to replace any of their
 75  older unconfirmed transactions with newer transactions, a feature called
 76  *full-RBF*.  This release includes a `mempoolfullrbf` configuration
 77  option that allows enabling full-RBF, although it defaults to off
 78  (allowing only opt-in RBF).
 79  
 80  Several alternative node implementations have already enabled full-RBF by
 81  default for years, and several contributors to Bitcoin Core are
 82  advocating for enabling full-RBF by default in a future version of
 83  Bitcoin Core.
 84  
 85  As more nodes that participate in relay and mining begin enabling
 86  full-RBF, replacement of unconfirmed transactions by ones offering higher
 87  fees may rapidly become more reliable.
 88  
 89  Contributors to this project strongly recommend that merchants and services
 90  not accept unconfirmed transactions as final, and if they insist on doing so,
 91  to take the appropriate steps to ensure they have some recourse or plan for
 92  when 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  
 97  Notable changes
 98  ===============
 99  
100  P2P 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  
123  Updated 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  
149  Changes to wallet related RPCs can be found in the Wallet section below.
150  
151  New 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  
170  Updated 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  
190  Build System
191  ------------
192  
193  - Guix builds are now reproducible across architectures (x86_64 & aarch64). (#21194)
194  
195  New 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  
202  Wallet
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  
235  Migrating Legacy Wallets to Descriptor Wallets
236  ---------------------------------------------
237  
238  An experimental RPC `migratewallet` has been added to migrate Legacy (non-descriptor) wallets to
239  Descriptor 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  
242  GUI 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,
248  proxy settings, UPNP preferences) are now saved to `<datadir>/settings.json`
249  file rather than to the Qt settings backend (windows registry or unix desktop
250  config files), so these settings will now apply to bitcoind, instead of being
251  ignored. (#15936, gui#602)
252  
253  - Also, the interaction between GUI settings and `bitcoin.conf` settings is
254  simplified. Settings from `bitcoin.conf` are now displayed normally in the GUI
255  settings dialog, instead of in a separate warning message ("Options set in this
256  dialog are overridden by the configuration file: -setting=value"). And these
257  settings can now be edited because `settings.json` values take precedence over
258  `bitcoin.conf` values. (#15936)
259  
260  Low-level changes
261  =================
262  
263  RPC
264  ---
265  
266  - The `deriveaddresses`, `getdescriptorinfo`, `importdescriptors` and `scantxoutset` commands now
267    accept Miniscript expression within a `wsh()` descriptor. (#24148)
268  
269  - The `getaddressinfo`, `decodescript`, `listdescriptors` and `listunspent` commands may now output
270    a Miniscript descriptor inside a `wsh()` where a `wsh(raw())` descriptor was previously returned. (#24148)
271  
272  Credits
273  =======
274  
275  Thanks to everyone who directly contributed to this release:
276  
277  - /dev/fd0
278  - 0xb10c
279  - Adam Jonas
280  - akankshakashyap
281  - Ali Sherief
282  - amadeuszpawlik
283  - Andreas Kouloumos
284  - Andrew Chow
285  - Anthony Towns
286  - Antoine Poinsot
287  - Antoine Riard
288  - Aurèle Oulès
289  - avirgovi
290  - Ayush Sharma
291  - Baas
292  - Ben Woosley
293  - BrokenProgrammer
294  - brunoerg
295  - brydinh
296  - Bushstar
297  - Calvin Kim
298  - CAnon
299  - Carl Dong
300  - chinggg
301  - Cory Fields
302  - Daniel Kraft
303  - Daniela Brozzoni
304  - darosior
305  - Dave Scotese
306  - David Bakin
307  - dergoegge
308  - dhruv
309  - Dimitri
310  - dontbyte
311  - Duncan Dean
312  - eugene
313  - Eunoia
314  - Fabian Jahr
315  - furszy
316  - Gleb Naumenko
317  - glozow
318  - Greg Weber
319  - Gregory Sanders
320  - gruve-p
321  - Hennadii Stepanov
322  - hiago
323  - Igor Bubelov
324  - ishaanam
325  - Jacob P.
326  - Jadi
327  - James O'Beirne
328  - Janna
329  - Jarol Rodriguez
330  - Jeremy Rand
331  - Jeremy Rubin
332  - jessebarton
333  - João Barbosa
334  - John Newbery
335  - Jon Atack
336  - Josiah Baker
337  - Karl-Johan Alm
338  - KevinMusgrave
339  - Kiminuo
340  - klementtan
341  - Kolby Moroz
342  - kouloumos
343  - Kristaps Kaupe
344  - Larry Ruane
345  - Luke Dashjr
346  - MarcoFalke
347  - Marnix
348  - Martin Leitner-Ankerl
349  - Martin Zumsande
350  - Michael Dietz
351  - Michael Folkson
352  - Michael Ford
353  - Murch
354  - mutatrum
355  - muxator
356  - Oskar Mendel
357  - Pablo Greco
358  - pasta
359  - Patrick Strateman
360  - Pavol Rusnak
361  - Peter Bushnell
362  - phyBrackets
363  - Pieter Wuille
364  - practicalswift
365  - randymcmillan
366  - Robert Spigler
367  - Russell Yanofsky
368  - S3RK
369  - Samer Afach
370  - Sebastian Falbesoner
371  - Seibart Nedor
372  - Shashwat
373  - Sjors Provoost
374  - Smlep
375  - sogoagain
376  - Stacie
377  - Stéphan Vuylsteke
378  - Suhail Saqan
379  - Suhas Daftuar
380  - t-bast
381  - TakeshiMusgrave
382  - Vasil Dimov
383  - W. J. van der Laan
384  - w0xlt
385  - whiteh0rse
386  - willcl-ark
387  - William Casarin
388  - Yancy Ribbens
389  
390  As well as to everyone that helped with translations on
391  [Transifex](https://www.transifex.com/bitcoin/bitcoin/).