diff options
author | fanquake <fanquake@gmail.com> | 2022-12-06 12:46:38 +0000 |
---|---|---|
committer | fanquake <fanquake@gmail.com> | 2022-12-06 14:10:45 +0000 |
commit | 896fca16a3818cc9102196863627e66d4d89307a (patch) | |
tree | 7ddf224215af354f87e6e00f7d76f87405403317 /doc/release-notes | |
parent | 8ccab65f289e3cce392cbe01d5fc0e7437f51f1e (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.md | 391 | ||||
-rw-r--r-- | doc/release-notes/release-notes-24.0.md | 390 |
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. |