aboutsummaryrefslogtreecommitdiff
path: root/doc/release-notes
diff options
context:
space:
mode:
authorfanquake <fanquake@gmail.com>2022-12-06 12:46:38 +0000
committerfanquake <fanquake@gmail.com>2022-12-06 14:10:45 +0000
commit896fca16a3818cc9102196863627e66d4d89307a (patch)
tree7ddf224215af354f87e6e00f7d76f87405403317 /doc/release-notes
parent8ccab65f289e3cce392cbe01d5fc0e7437f51f1e (diff)
doc: move release notes to 24.0.1 and add notice
This mirrors what was done with 0.19.0.1.
Diffstat (limited to 'doc/release-notes')
-rw-r--r--doc/release-notes/release-notes-24.0.1.md391
-rw-r--r--doc/release-notes/release-notes-24.0.md390
2 files changed, 394 insertions, 387 deletions
diff --git a/doc/release-notes/release-notes-24.0.1.md b/doc/release-notes/release-notes-24.0.1.md
new file mode 100644
index 0000000000..24920ba450
--- /dev/null
+++ b/doc/release-notes/release-notes-24.0.1.md
@@ -0,0 +1,391 @@
+24.0.1 Release Notes
+====================
+
+Due to last-minute issues (#26616), 24.0, although tagged, was never fully
+announced or released.
+
+Bitcoin Core version 24.0.1 is now available from:
+
+ <https://bitcoincore.org/bin/bitcoin-core-24.0.1/>
+
+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 macOS)
+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.15+, 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.
+
+Notice of new option for transaction replacement policies
+=========================================================
+
+This version of Bitcoin Core adds a new `mempoolfullrbf` configuration
+option which allows users to change the policy their individual node
+will use for relaying and mining unconfirmed transactions. The option
+defaults to the same policy that was used in previous releases and no
+changes to node policy will occur if everyone uses the default.
+
+Some Bitcoin services today expect that the first version of an
+unconfirmed transaction that they see will be the version of the
+transaction that ultimately gets confirmed---a transaction acceptance
+policy sometimes called "first-seen".
+
+The Bitcoin Protocol does not, and cannot, provide any assurance that
+the first version of an unconfirmed transaction seen by a particular
+node will be the version that gets confirmed. If there are multiple
+versions of the same unconfirmed transaction available, only the miner
+who includes one of those transactions in a block gets to decide which
+version of the transaction gets confirmed.
+
+Despite this lack of assurance, multiple merchants and services today
+still make this assumption.
+
+There are several benefits to users from removing this *first-seen*
+simplification. One key benefit, the ability for the sender of a
+transaction to replace it with an alternative version paying higher
+fees, was realized in [Bitcoin Core 0.12.0][] (February 2016) with the
+introduction of [BIP125][] opt-in Replace By Fee (RBF).
+
+Since then, there has been discussion about completely removing the
+first-seen simplification and allowing users to replace any of their
+older unconfirmed transactions with newer transactions, a feature called
+*full-RBF*. This release includes a `mempoolfullrbf` configuration
+option that allows enabling full-RBF, although it defaults to off
+(allowing only opt-in RBF).
+
+Several alternative node implementations have already enabled full-RBF by
+default for years, and several contributors to Bitcoin Core are
+advocating for enabling full-RBF by default in a future version of
+Bitcoin Core.
+
+As more nodes that participate in relay and mining begin enabling
+full-RBF, replacement of unconfirmed transactions by ones offering higher
+fees may rapidly become more reliable.
+
+Contributors to this project strongly recommend that merchants and services
+not accept unconfirmed transactions as final, and if they insist on doing so,
+to take the appropriate steps to ensure they have some recourse or plan for
+when their assumptions do not hold.
+
+[Bitcoin Core 0.12.0]: https://bitcoincore.org/en/releases/0.12.0/#opt-in-replace-by-fee-transactions
+[bip125]: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki
+
+Notable changes
+===============
+
+P2P and network changes
+-----------------------
+
+- To address a potential denial-of-service, the logic to download headers from peers
+ has been reworked. This is particularly relevant for nodes starting up for the
+ first time (or for nodes which are starting up after being offline for a long time).
+
+ Whenever headers are received from a peer that have a total chainwork that is either
+ less than the node's `-minimumchainwork` value or is sufficiently below the work at
+ the node's tip, a "presync" phase will begin, in which the node will download the
+ peer's headers and verify the cumulative work on the peer's chain, prior to storing
+ those headers permanently. Once that cumulative work is verified to be sufficiently high,
+ the headers will be redownloaded from that peer and fully validated and stored.
+
+ This may result in initial headers sync taking longer for new nodes starting up for
+ the first time, both because the headers will be downloaded twice, and because the effect
+ of a peer disconnecting during the presync phase (or while the node's best headers chain has less
+ than `-minimumchainwork`), will result in the node needing to use the headers presync mechanism
+ with the next peer as well (downloading the headers twice, again). (#25717)
+
+- With I2P connections, a new, transient address is used for each outbound
+ connection if `-i2pacceptincoming=0`. (#25355)
+
+Updated RPCs
+------------
+
+- The `-deprecatedrpc=softforks` configuration option has been removed. The
+ RPC `getblockchaininfo` no longer returns the `softforks` field, which was
+ previously deprecated in 23.0. (#23508) Information on soft fork status is
+ now only available via the `getdeploymentinfo` RPC.
+
+- The `deprecatedrpc=exclude_coinbase` configuration option has been removed.
+ The `receivedby` RPCs (`listreceivedbyaddress`, `listreceivedbylabel`,
+ `getreceivedbyaddress` and `getreceivedbylabel`) now always return results
+ accounting for received coins from coinbase outputs, without an option to
+ change that behaviour. Excluding coinbases was previously deprecated in 23.0.
+ (#25171)
+
+- The `deprecatedrpc=fees` configuration option has been removed. The top-level
+ fee fields `fee`, `modifiedfee`, `ancestorfees` and `descendantfees` are no
+ longer returned by RPCs `getmempoolentry`, `getrawmempool(verbose=true)`,
+ `getmempoolancestors(verbose=true)` and `getmempooldescendants(verbose=true)`.
+ The same fee fields can be accessed through the `fees` object in the result.
+ The top-level fee fields were previously deprecated in 23.0. (#25204)
+
+- The `getpeerinfo` RPC has been updated with a new `presynced_headers` field,
+ indicating the progress on the presync phase mentioned in the
+ "P2P and network changes" section above.
+
+Changes to wallet related RPCs can be found in the Wallet section below.
+
+New RPCs
+--------
+
+- The `sendall` RPC spends specific UTXOs to one or more recipients
+ without creating change. By default, the `sendall` RPC will spend
+ every UTXO in the wallet. `sendall` is useful to empty wallets or to
+ create a changeless payment from select UTXOs. When creating a payment
+ from a specific amount for which the recipient incurs the transaction
+ fee, continue to use the `subtractfeefromamount` option via the
+ `send`, `sendtoaddress`, or `sendmany` RPCs. (#24118)
+
+- A new `gettxspendingprevout` RPC has been added, which scans the mempool to find
+ transactions spending any of the given outpoints. (#24408)
+
+- The `simulaterawtransaction` RPC iterates over the inputs and outputs of the given
+ transactions, and tallies up the balance change for the given wallet. This can be
+ useful e.g. when verifying that a coin join like transaction doesn't contain unexpected
+ inputs that the wallet will then sign for unintentionally. (#22751)
+
+Updated REST APIs
+-----------------
+
+- The `/headers/` and `/blockfilterheaders/` endpoints have been updated to use
+ a query parameter instead of path parameter to specify the result count. The
+ count parameter is now optional, and defaults to 5 for both endpoints. The old
+ endpoints are still functional, and have no documented behaviour change.
+
+ For `/headers`, use
+ `GET /rest/headers/<BLOCK-HASH>.<bin|hex|json>?count=<COUNT=5>`
+ instead of
+ `GET /rest/headers/<COUNT>/<BLOCK-HASH>.<bin|hex|json>` (deprecated)
+
+ For `/blockfilterheaders/`, use
+ `GET /rest/blockfilterheaders/<FILTERTYPE>/<BLOCK-HASH>.<bin|hex|json>?count=<COUNT=5>`
+ instead of
+ `GET /rest/blockfilterheaders/<FILTERTYPE>/<COUNT>/<BLOCK-HASH>.<bin|hex|json>` (deprecated)
+
+ (#24098)
+
+Build System
+------------
+
+- Guix builds are now reproducible across architectures (x86_64 & aarch64). (#21194)
+
+New settings
+------------
+
+- A new `mempoolfullrbf` option has been added, which enables the mempool to
+ accept transaction replacement without enforcing BIP125 replaceability
+ signaling. (#25353)
+
+Wallet
+------
+
+- The `-walletrbf` startup option will now default to `true`. The
+ wallet will now default to opt-in RBF on transactions that it creates. (#25610)
+
+- The `replaceable` option for the `createrawtransaction` and
+ `createpsbt` RPCs will now default to `true`. Transactions created
+ with these RPCs will default to having opt-in RBF enabled. (#25610)
+
+- The `wsh()` output descriptor was extended with Miniscript support. You can import Miniscript
+ descriptors for P2WSH in a watchonly wallet to track coins, but you can't spend from them using
+ the Bitcoin Core wallet yet.
+ You can find more about Miniscript on the [reference website](https://bitcoin.sipa.be/miniscript/). (#24148)
+
+- The `tr()` output descriptor now supports multisig scripts through the `multi_a()` and
+ `sortedmulti_a()` functions. (#24043)
+
+- To help prevent fingerprinting transactions created by the Bitcoin Core wallet, change output
+ amounts are now randomized. (#24494)
+
+- The `listtransactions`, `gettransaction`, and `listsinceblock`
+ RPC methods now include a wtxid field (hash of serialized transaction,
+ including witness data) for each transaction. (#24198)
+
+- The `listsinceblock`, `listtransactions` and `gettransaction` output now contain a new
+ `parent_descs` field for every "receive" entry. (#25504)
+
+- A new optional `include_change` parameter was added to the `listsinceblock` command.
+
+- RPC `getreceivedbylabel` now returns an error, "Label not found
+ in wallet" (-4), if the label is not in the address book. (#25122)
+
+Migrating Legacy Wallets to Descriptor Wallets
+---------------------------------------------
+
+An experimental RPC `migratewallet` has been added to migrate Legacy (non-descriptor) wallets to
+Descriptor wallets. More information about the migration process is available in the
+[documentation](https://github.com/bitcoin/bitcoin/blob/master/doc/managing-wallets.md#migrating-legacy-wallets-to-descriptor-wallets).
+
+GUI changes
+-----------
+
+- A new menu item to restore a wallet from a backup file has been added (gui#471).
+
+- Configuration changes made in the bitcoin GUI (such as the pruning setting,
+proxy settings, UPNP preferences) are now saved to `<datadir>/settings.json`
+file rather than to the Qt settings backend (windows registry or unix desktop
+config files), so these settings will now apply to bitcoind, instead of being
+ignored. (#15936, gui#602)
+
+- Also, the interaction between GUI settings and `bitcoin.conf` settings is
+simplified. Settings from `bitcoin.conf` are now displayed normally in the GUI
+settings dialog, instead of in a separate warning message ("Options set in this
+dialog are overridden by the configuration file: -setting=value"). And these
+settings can now be edited because `settings.json` values take precedence over
+`bitcoin.conf` values. (#15936)
+
+Low-level changes
+=================
+
+RPC
+---
+
+- The `deriveaddresses`, `getdescriptorinfo`, `importdescriptors` and `scantxoutset` commands now
+ accept Miniscript expression within a `wsh()` descriptor. (#24148)
+
+- The `getaddressinfo`, `decodescript`, `listdescriptors` and `listunspent` commands may now output
+ a Miniscript descriptor inside a `wsh()` where a `wsh(raw())` descriptor was previously returned. (#24148)
+
+Credits
+=======
+
+Thanks to everyone who directly contributed to this release:
+
+- /dev/fd0
+- 0xb10c
+- Adam Jonas
+- akankshakashyap
+- Ali Sherief
+- amadeuszpawlik
+- Andreas Kouloumos
+- Andrew Chow
+- Anthony Towns
+- Antoine Poinsot
+- Antoine Riard
+- Aurèle Oulès
+- avirgovi
+- Ayush Sharma
+- Baas
+- Ben Woosley
+- BrokenProgrammer
+- brunoerg
+- brydinh
+- Bushstar
+- Calvin Kim
+- CAnon
+- Carl Dong
+- chinggg
+- Cory Fields
+- Daniel Kraft
+- Daniela Brozzoni
+- darosior
+- Dave Scotese
+- David Bakin
+- dergoegge
+- dhruv
+- Dimitri
+- dontbyte
+- Duncan Dean
+- eugene
+- Eunoia
+- Fabian Jahr
+- furszy
+- Gleb Naumenko
+- glozow
+- Greg Weber
+- Gregory Sanders
+- gruve-p
+- Hennadii Stepanov
+- hiago
+- Igor Bubelov
+- ishaanam
+- Jacob P.
+- Jadi
+- James O'Beirne
+- Janna
+- Jarol Rodriguez
+- Jeremy Rand
+- Jeremy Rubin
+- jessebarton
+- João Barbosa
+- John Newbery
+- Jon Atack
+- Josiah Baker
+- Karl-Johan Alm
+- KevinMusgrave
+- Kiminuo
+- klementtan
+- Kolby Moroz
+- kouloumos
+- Kristaps Kaupe
+- Larry Ruane
+- Luke Dashjr
+- MarcoFalke
+- Marnix
+- Martin Leitner-Ankerl
+- Martin Zumsande
+- Michael Dietz
+- Michael Folkson
+- Michael Ford
+- Murch
+- mutatrum
+- muxator
+- Oskar Mendel
+- Pablo Greco
+- pasta
+- Patrick Strateman
+- Pavol Rusnak
+- Peter Bushnell
+- phyBrackets
+- Pieter Wuille
+- practicalswift
+- randymcmillan
+- Robert Spigler
+- Russell Yanofsky
+- S3RK
+- Samer Afach
+- Sebastian Falbesoner
+- Seibart Nedor
+- Shashwat
+- Sjors Provoost
+- Smlep
+- sogoagain
+- Stacie
+- Stéphan Vuylsteke
+- Suhail Saqan
+- Suhas Daftuar
+- t-bast
+- TakeshiMusgrave
+- Vasil Dimov
+- W. J. van der Laan
+- w0xlt
+- whiteh0rse
+- willcl-ark
+- William Casarin
+- Yancy Ribbens
+
+As well as to everyone that helped with translations on
+[Transifex](https://www.transifex.com/bitcoin/bitcoin/).
diff --git a/doc/release-notes/release-notes-24.0.md b/doc/release-notes/release-notes-24.0.md
index a9240567d7..a0227aa17f 100644
--- a/doc/release-notes/release-notes-24.0.md
+++ b/doc/release-notes/release-notes-24.0.md
@@ -1,388 +1,4 @@
-24.0 Release Notes
-==================
+Due to last-minute issues (#26616), 24.0, although tagged, was never fully
+announced or released.
-Bitcoin Core version 24.0 is now available from:
-
- <https://bitcoincore.org/bin/bitcoin-core-24.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 macOS)
-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.15+, 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.
-
-Notice of new option for transaction replacement policies
-=========================================================
-
-This version of Bitcoin Core adds a new `mempoolfullrbf` configuration
-option which allows users to change the policy their individual node
-will use for relaying and mining unconfirmed transactions. The option
-defaults to the same policy that was used in previous releases and no
-changes to node policy will occur if everyone uses the default.
-
-Some Bitcoin services today expect that the first version of an
-unconfirmed transaction that they see will be the version of the
-transaction that ultimately gets confirmed---a transaction acceptance
-policy sometimes called "first-seen".
-
-The Bitcoin Protocol does not, and cannot, provide any assurance that
-the first version of an unconfirmed transaction seen by a particular
-node will be the version that gets confirmed. If there are multiple
-versions of the same unconfirmed transaction available, only the miner
-who includes one of those transactions in a block gets to decide which
-version of the transaction gets confirmed.
-
-Despite this lack of assurance, multiple merchants and services today
-still make this assumption.
-
-There are several benefits to users from removing this *first-seen*
-simplification. One key benefit, the ability for the sender of a
-transaction to replace it with an alternative version paying higher
-fees, was realized in [Bitcoin Core 0.12.0][] (February 2016) with the
-introduction of [BIP125][] opt-in Replace By Fee (RBF).
-
-Since then, there has been discussion about completely removing the
-first-seen simplification and allowing users to replace any of their
-older unconfirmed transactions with newer transactions, a feature called
-*full-RBF*. This release includes a `mempoolfullrbf` configuration
-option that allows enabling full-RBF, although it defaults to off
-(allowing only opt-in RBF).
-
-Several alternative node implementations have already enabled full-RBF by
-default for years, and several contributors to Bitcoin Core are
-advocating for enabling full-RBF by default in a future version of
-Bitcoin Core.
-
-As more nodes that participate in relay and mining begin enabling
-full-RBF, replacement of unconfirmed transactions by ones offering higher
-fees may rapidly become more reliable.
-
-Contributors to this project strongly recommend that merchants and services
-not accept unconfirmed transactions as final, and if they insist on doing so,
-to take the appropriate steps to ensure they have some recourse or plan for
-when their assumptions do not hold.
-
-[Bitcoin Core 0.12.0]: https://bitcoincore.org/en/releases/0.12.0/#opt-in-replace-by-fee-transactions
-[bip125]: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki
-
-Notable changes
-===============
-
-P2P and network changes
------------------------
-
-- To address a potential denial-of-service, the logic to download headers from peers
- has been reworked. This is particularly relevant for nodes starting up for the
- first time (or for nodes which are starting up after being offline for a long time).
-
- Whenever headers are received from a peer that have a total chainwork that is either
- less than the node's `-minimumchainwork` value or is sufficiently below the work at
- the node's tip, a "presync" phase will begin, in which the node will download the
- peer's headers and verify the cumulative work on the peer's chain, prior to storing
- those headers permanently. Once that cumulative work is verified to be sufficiently high,
- the headers will be redownloaded from that peer and fully validated and stored.
-
- This may result in initial headers sync taking longer for new nodes starting up for
- the first time, both because the headers will be downloaded twice, and because the effect
- of a peer disconnecting during the presync phase (or while the node's best headers chain has less
- than `-minimumchainwork`), will result in the node needing to use the headers presync mechanism
- with the next peer as well (downloading the headers twice, again). (#25717)
-
-- With I2P connections, a new, transient address is used for each outbound
- connection if `-i2pacceptincoming=0`. (#25355)
-
-Updated RPCs
-------------
-
-- The `-deprecatedrpc=softforks` configuration option has been removed. The
- RPC `getblockchaininfo` no longer returns the `softforks` field, which was
- previously deprecated in 23.0. (#23508) Information on soft fork status is
- now only available via the `getdeploymentinfo` RPC.
-
-- The `deprecatedrpc=exclude_coinbase` configuration option has been removed.
- The `receivedby` RPCs (`listreceivedbyaddress`, `listreceivedbylabel`,
- `getreceivedbyaddress` and `getreceivedbylabel`) now always return results
- accounting for received coins from coinbase outputs, without an option to
- change that behaviour. Excluding coinbases was previously deprecated in 23.0.
- (#25171)
-
-- The `deprecatedrpc=fees` configuration option has been removed. The top-level
- fee fields `fee`, `modifiedfee`, `ancestorfees` and `descendantfees` are no
- longer returned by RPCs `getmempoolentry`, `getrawmempool(verbose=true)`,
- `getmempoolancestors(verbose=true)` and `getmempooldescendants(verbose=true)`.
- The same fee fields can be accessed through the `fees` object in the result.
- The top-level fee fields were previously deprecated in 23.0. (#25204)
-
-- The `getpeerinfo` RPC has been updated with a new `presynced_headers` field,
- indicating the progress on the presync phase mentioned in the
- "P2P and network changes" section above.
-
-Changes to wallet related RPCs can be found in the Wallet section below.
-
-New RPCs
---------
-
-- The `sendall` RPC spends specific UTXOs to one or more recipients
- without creating change. By default, the `sendall` RPC will spend
- every UTXO in the wallet. `sendall` is useful to empty wallets or to
- create a changeless payment from select UTXOs. When creating a payment
- from a specific amount for which the recipient incurs the transaction
- fee, continue to use the `subtractfeefromamount` option via the
- `send`, `sendtoaddress`, or `sendmany` RPCs. (#24118)
-
-- A new `gettxspendingprevout` RPC has been added, which scans the mempool to find
- transactions spending any of the given outpoints. (#24408)
-
-- The `simulaterawtransaction` RPC iterates over the inputs and outputs of the given
- transactions, and tallies up the balance change for the given wallet. This can be
- useful e.g. when verifying that a coin join like transaction doesn't contain unexpected
- inputs that the wallet will then sign for unintentionally. (#22751)
-
-Updated REST APIs
------------------
-
-- The `/headers/` and `/blockfilterheaders/` endpoints have been updated to use
- a query parameter instead of path parameter to specify the result count. The
- count parameter is now optional, and defaults to 5 for both endpoints. The old
- endpoints are still functional, and have no documented behaviour change.
-
- For `/headers`, use
- `GET /rest/headers/<BLOCK-HASH>.<bin|hex|json>?count=<COUNT=5>`
- instead of
- `GET /rest/headers/<COUNT>/<BLOCK-HASH>.<bin|hex|json>` (deprecated)
-
- For `/blockfilterheaders/`, use
- `GET /rest/blockfilterheaders/<FILTERTYPE>/<BLOCK-HASH>.<bin|hex|json>?count=<COUNT=5>`
- instead of
- `GET /rest/blockfilterheaders/<FILTERTYPE>/<COUNT>/<BLOCK-HASH>.<bin|hex|json>` (deprecated)
-
- (#24098)
-
-Build System
-------------
-
-- Guix builds are now reproducible across architectures (x86_64 & aarch64). (#21194)
-
-New settings
-------------
-
-- A new `mempoolfullrbf` option has been added, which enables the mempool to
- accept transaction replacement without enforcing BIP125 replaceability
- signaling. (#25353)
-
-Wallet
-------
-
-- The `-walletrbf` startup option will now default to `true`. The
- wallet will now default to opt-in RBF on transactions that it creates. (#25610)
-
-- The `replaceable` option for the `createrawtransaction` and
- `createpsbt` RPCs will now default to `true`. Transactions created
- with these RPCs will default to having opt-in RBF enabled. (#25610)
-
-- The `wsh()` output descriptor was extended with Miniscript support. You can import Miniscript
- descriptors for P2WSH in a watchonly wallet to track coins, but you can't spend from them using
- the Bitcoin Core wallet yet.
- You can find more about Miniscript on the [reference website](https://bitcoin.sipa.be/miniscript/). (#24148)
-
-- The `tr()` output descriptor now supports multisig scripts through the `multi_a()` and
- `sortedmulti_a()` functions. (#24043)
-
-- To help prevent fingerprinting transactions created by the Bitcoin Core wallet, change output
- amounts are now randomized. (#24494)
-
-- The `listtransactions`, `gettransaction`, and `listsinceblock`
- RPC methods now include a wtxid field (hash of serialized transaction,
- including witness data) for each transaction. (#24198)
-
-- The `listsinceblock`, `listtransactions` and `gettransaction` output now contain a new
- `parent_descs` field for every "receive" entry. (#25504)
-
-- A new optional `include_change` parameter was added to the `listsinceblock` command.
-
-- RPC `getreceivedbylabel` now returns an error, "Label not found
- in wallet" (-4), if the label is not in the address book. (#25122)
-
-Migrating Legacy Wallets to Descriptor Wallets
----------------------------------------------
-
-An experimental RPC `migratewallet` has been added to migrate Legacy (non-descriptor) wallets to
-Descriptor wallets. More information about the migration process is available in the
-[documentation](https://github.com/bitcoin/bitcoin/blob/master/doc/managing-wallets.md#migrating-legacy-wallets-to-descriptor-wallets).
-
-GUI changes
------------
-
-- A new menu item to restore a wallet from a backup file has been added (gui#471).
-
-- Configuration changes made in the bitcoin GUI (such as the pruning setting,
-proxy settings, UPNP preferences) are now saved to `<datadir>/settings.json`
-file rather than to the Qt settings backend (windows registry or unix desktop
-config files), so these settings will now apply to bitcoind, instead of being
-ignored. (#15936, gui#602)
-
-- Also, the interaction between GUI settings and `bitcoin.conf` settings is
-simplified. Settings from `bitcoin.conf` are now displayed normally in the GUI
-settings dialog, instead of in a separate warning message ("Options set in this
-dialog are overridden by the configuration file: -setting=value"). And these
-settings can now be edited because `settings.json` values take precedence over
-`bitcoin.conf` values. (#15936)
-
-Low-level changes
-=================
-
-RPC
----
-
-- The `deriveaddresses`, `getdescriptorinfo`, `importdescriptors` and `scantxoutset` commands now
- accept Miniscript expression within a `wsh()` descriptor. (#24148)
-
-- The `getaddressinfo`, `decodescript`, `listdescriptors` and `listunspent` commands may now output
- a Miniscript descriptor inside a `wsh()` where a `wsh(raw())` descriptor was previously returned. (#24148)
-
-Credits
-=======
-
-Thanks to everyone who directly contributed to this release:
-
-- /dev/fd0
-- 0xb10c
-- Adam Jonas
-- akankshakashyap
-- Ali Sherief
-- amadeuszpawlik
-- Andreas Kouloumos
-- Andrew Chow
-- Anthony Towns
-- Antoine Poinsot
-- Antoine Riard
-- Aurèle Oulès
-- avirgovi
-- Ayush Sharma
-- Baas
-- Ben Woosley
-- BrokenProgrammer
-- brunoerg
-- brydinh
-- Bushstar
-- Calvin Kim
-- CAnon
-- Carl Dong
-- chinggg
-- Cory Fields
-- Daniel Kraft
-- Daniela Brozzoni
-- darosior
-- Dave Scotese
-- David Bakin
-- dergoegge
-- dhruv
-- Dimitri
-- dontbyte
-- Duncan Dean
-- eugene
-- Eunoia
-- Fabian Jahr
-- furszy
-- Gleb Naumenko
-- glozow
-- Greg Weber
-- Gregory Sanders
-- gruve-p
-- Hennadii Stepanov
-- hiago
-- Igor Bubelov
-- ishaanam
-- Jacob P.
-- Jadi
-- James O'Beirne
-- Janna
-- Jarol Rodriguez
-- Jeremy Rand
-- Jeremy Rubin
-- jessebarton
-- João Barbosa
-- John Newbery
-- Jon Atack
-- Josiah Baker
-- Karl-Johan Alm
-- KevinMusgrave
-- Kiminuo
-- klementtan
-- Kolby Moroz
-- kouloumos
-- Kristaps Kaupe
-- Larry Ruane
-- Luke Dashjr
-- MarcoFalke
-- Marnix
-- Martin Leitner-Ankerl
-- Martin Zumsande
-- Michael Dietz
-- Michael Folkson
-- Michael Ford
-- Murch
-- mutatrum
-- muxator
-- Oskar Mendel
-- Pablo Greco
-- pasta
-- Patrick Strateman
-- Pavol Rusnak
-- Peter Bushnell
-- phyBrackets
-- Pieter Wuille
-- practicalswift
-- randymcmillan
-- Robert Spigler
-- Russell Yanofsky
-- S3RK
-- Samer Afach
-- Sebastian Falbesoner
-- Seibart Nedor
-- Shashwat
-- Sjors Provoost
-- Smlep
-- sogoagain
-- Stacie
-- Stéphan Vuylsteke
-- Suhail Saqan
-- Suhas Daftuar
-- t-bast
-- TakeshiMusgrave
-- Vasil Dimov
-- W. J. van der Laan
-- w0xlt
-- whiteh0rse
-- willcl-ark
-- William Casarin
-- Yancy Ribbens
-
-As well as to everyone that helped with translations on
-[Transifex](https://www.transifex.com/bitcoin/bitcoin/).
+See the release notes for 24.0.1 instead.