Bump version to v24.0. Regenerate manpages. Pull in the release notes from the devwiki:
@stickies-v RPC diff summary between 24.0 and 23.0 in https://github.com/bitcoin-core/bitcoincore.org/pull/919 shows the following new RPCs.
I've moved the https://github.com/bitcoin-core/bitcoin-devwiki/wiki/24.0-Release-Notes-draft#migrating-legacy-wallets-to-descriptor-wallets section to "New RPCs" and added simulaterawtransaction.
and added simulaterawtransaction.
Included that change here.
I've moved the https://github.com/bitcoin-core/bitcoin-devwiki/wiki/24.0-Release-Notes-draft#migrating-legacy-wallets-to-descriptor-wallets section to "New RPCs"
Not sure, as it might be worthwhile having the callout for this in the Wallet section. Thoughts @achow101?
192 | +New settings 193 | +------------ 194 | + 195 | +- A new `mempoolfullrbf` option has been added, which enables the mempool to 196 | + accept transaction replacement without enforcing BIP125 replaceability 197 | + signaling. (#25353)
Should doc/bips.md be amended with this?
* [`BIP 125`](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki): Opt-in full replace-by-fee signaling partially implemented. Full replace-by-fee enabled as a configurable mempool policy as of **v24.0** ([PR
[#25353](/bitcoin-bitcoin/25353/)](https://github.com/bitcoin/bitcoin/pull/25353)). See doc/policy/mempool-replacements.md.
Going to leave this for now.
63 | + 64 | +There are several benefits to users from removing this *first-seen* 65 | +simplification. One key benefit, the ability for the sender of a 66 | +transaction to replace it with an alternative version paying higher 67 | +fees, was realized in [Bitcoin Core 0.12.0][] (February 2016) with the 68 | +introduction of [BIP125][] opt-in Replace By Fee (RBF).
It looks like these were meant to be hyperlinks?
fees, was realized in [Bitcoin Core 0.12.0](https://bitcoincore.org/en/2016/02/23/release-0.12.0/) (February 2016) with the
introduction of [BIP125](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki) opt-in Replace By Fee (RBF).
link is below and seems to render properly, markdown magic perhaps
going to leave this as-is then
47 | +changes to node policy will occur if everyone uses the default. 48 | + 49 | +Some Bitcoin services today expect that the first version of an 50 | +unconfirmed transaction that they see will be the version of the 51 | +transaction that ultimately gets confirmed---a transaction acceptance 52 | +policy sometimes called "first seen".
consistent spelling
policy sometimes called "first-seen".
368 | +- Shashwat 369 | +- Sjors Provoost 370 | +- Smlep 371 | +- sogoagain 372 | +- Stacie 373 | +- stickies-v
- Stéphan Vuylsteke
I verified that the steps in doc/release-process.md for "Before every major and minor release" and "Before every major release" were followed (modulo my comment re bips.md).
Left a few suggestions, but generally LGTM.
Quickly skimmed through the release notes, and they look good to me. Including and particularly the text on the new mempoolfullrbf option.
326 | +- jessebarton 327 | +- João Barbosa 328 | +- John Newbery 329 | +- Jon Atack 330 | +- Josiah Baker 331 | +- josibake
Some duplicates: Josiah Baker / josibake Russell Yanofsky / Ryan Ofsky
Thanks. Addressed both.
Looks good to me.
I've moved the https://github.com/bitcoin-core/bitcoin-devwiki/wiki/24.0-Release-Notes-draft#migrating-legacy-wallets-to-descriptor-wallets section to "New RPCs"
Not sure, as it might be worthwhile having the callout for this in the Wallet section. Thoughts @achow101?
Wallet section (or it's own section) would be better than in "New RPCs"
229 | +An experimental RPC `migratewallet` has been added to migrate Legacy (non-descriptor) wallets to 230 | +Descriptor wallets. More information about the migration process is available in the 231 | +[documentation](https://github.com/bitcoin/bitcoin/blob/master/doc/managing-wallets.md#migrating-legacy-wallets-to-descriptor-wallets). 232 | + 233 | +- RPC `getreceivedbylabel` now returns an error, "Label not found 234 | + in wallet" (-4), if the label is not in the address book. (#25122)
This appears to be in the wrong section.
Moved up into the wallet section.
FYI, there was an alternative version of the mempoolfullrbf text that was reviewed by multiple people here: https://gist.github.com/harding/f3cd8affb10cea96d352347fed7f4a3a
ACK 190709e456ba1a34c0f7270d07890db2a1b96af2
ACK release notes
@jonatack relates on IRC: "[The backports in #26457] may appear minor, but without them v24 will break user space. For example, the CashApp crypto team informed me that v24 will break their production systems if they upgrade without those patches. I've been proposing to fix these since August before v24 branch-off. If we go forward as-is, it seems to me the v24 release notes ought to warn about the changes (last I looked a few days ago, there was no mention of it)."
0 | @@ -0,0 +1,385 @@ 1 | +24.0 Release Notes 2 | +================== 3 | + 4 | +Bitcoin Core version *24.0* is now available from:
Bitcoin Core version 24.0 is now available from:
19 | +How to Upgrade 20 | +============== 21 | + 22 | +If you are running an older version, shut it down. Wait until it has completely 23 | +shut down (which might take a few minutes in some cases), then run the 24 | +installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on macOS)
234 | +[documentation](https://github.com/bitcoin/bitcoin/blob/master/doc/managing-wallets.md#migrating-legacy-wallets-to-descriptor-wallets). 235 | + 236 | +GUI changes 237 | +----------- 238 | + 239 | +- A new menu item to restore a wallet from a backup file has been added (#471).
- A new menu item to restore a wallet from a backup file has been added (gui#471).
240 | + 241 | +- Configuration changes made in the bitcoin GUI (such as the pruning setting, 242 | +proxy settings, UPNP preferences) are now saved to `<datadir>/settings.json` 243 | +file rather than to the Qt settings backend (windows registry or unix desktop 244 | +config files), so these settings will now apply to bitcoind, instead of being 245 | +ignored. (#15936)
ignored. (#15936, gui#602)
ACK 190709e456ba1a34c0f7270d07890db2a1b96af2
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--021abf342d371248e50ceaed478a90ca-->
See the guideline for information on the review process.
| Type | Count | Reviewers |
|---|---|---|
| ACK | 1 | 0xB10C |
| Stale ACK | 3 | LarryRuane, achow101, hebasto |
re-ACK 8810fbd33c1e85709b315775dc35dc3698482777
208 | + 209 | +- The `wsh()` output descriptor was extended with Miniscript support. You can import Miniscript 210 | + descriptors for P2WSH in a watchonly wallet to track coins, but you can't spend from them using 211 | + the Bitcoin Core wallet yet. 212 | + You can find more about Miniscript on the [reference website](https://bitcoin.sipa.be/miniscript/). (#24148) 213 | +
- If there are items that should be in the release notes, and are still missing, please comment.
Maybe #24043 could be mentioned here?
- The `tr()` output descriptor now supports multisig scripts through the `multi_a()` and `sortedmulti_a()` functions.
Added.
97 | +P2P and network changes 98 | +----------------------- 99 | + 100 | +- To address a potential denial-of-service, the logic to download headers from peers 101 | + has been reworked. This is particularly relevant for nodes starting up for the 102 | + first time (or for nodes which are starting up after being offline for a long time).
first time (or for nodes that are starting up after being offline for a long time).
100 | +- To address a potential denial-of-service, the logic to download headers from peers 101 | + has been reworked. This is particularly relevant for nodes starting up for the 102 | + first time (or for nodes which are starting up after being offline for a long time). 103 | + 104 | + Whenever headers are received from a peer that have a total chainwork that is either 105 | + less than the node's `-minimumchainwork` value or is sufficiently below the work at
-minimumchainwork is ArgsManager::DEBUG_ONLY so users may not know what this is (without source code). It may be better to just refer to the node's "hard-coded minimum chainwork" without indicating that it's an option.
I think this is fine.
109 | + the headers will be redownloaded from that peer and fully validated and stored. 110 | + 111 | + This may result in initial headers sync taking longer for new nodes starting up for 112 | + the first time, both because the headers will be downloaded twice, and because the effect 113 | + of a peer disconnecting during the presync phase (or while the node's best headers chain has less 114 | + than `-minimumchainwork`), will result in the node needing to use the headers presync mechanism
(see comment above)
104 | + Whenever headers are received from a peer that have a total chainwork that is either 105 | + less than the node's `-minimumchainwork` value or is sufficiently below the work at 106 | + the node's tip, a "presync" phase will begin, in which the node will download the 107 | + peer's headers and verify the cumulative work on the peer's chain, prior to storing 108 | + those headers permanently. Once that cumulative work is verified to be sufficiently high, 109 | + the headers will be redownloaded from that peer and fully validated and stored.
redownloaded
Just to forestall concern about IBD (or more generally, sync) taking much longer, would it be worth mentioning that header sync takes a small fraction of the total sync time? (In my experience, it's just a few minutes out of many hours or even days.)
Going to leave this as is
102 | + first time (or for nodes which are starting up after being offline for a long time). 103 | + 104 | + Whenever headers are received from a peer that have a total chainwork that is either 105 | + less than the node's `-minimumchainwork` value or is sufficiently below the work at 106 | + the node's tip, a "presync" phase will begin, in which the node will download the 107 | + peer's headers and verify the cumulative work on the peer's chain, prior to storing
peer's headers and verify the cumulative work on the peer's chain before storing
125 | + previously deprecated in 23.0. (#23508) Information on soft fork status is 126 | + now only available via the `getdeploymentinfo` RPC. 127 | + 128 | +- The `deprecatedrpc=exclude_coinbase` configuration option has been removed. 129 | + The `receivedby` RPCs (`listreceivedbyaddress`, `listreceivedbylabel`, 130 | + `getreceivedbyaddress` and `getreceivedbylabel`) now always return results
`getreceivedbyaddress`, and `getreceivedbylabel`) now always return results
Leaving all these without these commas.
133 | + (#25171) 134 | + 135 | +- The `deprecatedrpc=fees` configuration option has been removed. The top-level 136 | + fee fields `fee`, `modifiedfee`, `ancestorfees` and `descendantfees` are no 137 | + longer returned by RPCs `getmempoolentry`, `getrawmempool(verbose=true)`, 138 | + `getmempoolancestors(verbose=true)` and `getmempooldescendants(verbose=true)`.
`getmempoolancestors(verbose=true)`, and `getmempooldescendants(verbose=true)`.
219 | + 220 | +- The `listtransactions`, `gettransaction`, and `listsinceblock` 221 | + RPC methods now include a wtxid field (hash of serialized transaction, 222 | + including witness data) for each transaction. (#24198) 223 | + 224 | +- The `listsinceblock`, `listtransactions` and `gettransaction` output now contain a new
- The `listsinceblock`, `listtransactions`, and `gettransaction` output now contain a new
0 | @@ -0,0 +1,388 @@ 1 | +24.0 Release Notes 2 | +================== 3 | + 4 | +Bitcoin Core version 24.0 is now available from: 5 | + 6 | + <https://bitcoincore.org/bin/bitcoin-core-24.0/> 7 | + 8 | +This release includes new features, various bug fixes and performance
This release includes new features, various bug fixes, and performance
41 | +========================================================= 42 | + 43 | +This version of Bitcoin Core adds a new `mempoolfullrbf` configuration 44 | +option which allows users to change the policy their individual node 45 | +will use for relaying and mining unconfirmed transactions. The option 46 | +defaults to the same policy that was used in previous releases and no
defaults to the same policy that was used in previous releases; no
258 | +================= 259 | + 260 | +RPC 261 | +--- 262 | + 263 | +- The `deriveaddresses`, `getdescriptorinfo`, `importdescriptors` and `scantxoutset` commands now
- The `deriveaddresses`, `getdescriptorinfo`, `importdescriptors`, and `scantxoutset` commands now
261 | +--- 262 | + 263 | +- The `deriveaddresses`, `getdescriptorinfo`, `importdescriptors` and `scantxoutset` commands now 264 | + accept Miniscript expression within a `wsh()` descriptor. (#24148) 265 | + 266 | +- The `getaddressinfo`, `decodescript`, `listdescriptors` and `listunspent` commands may now output
- The `getaddressinfo`, `decodescript`, `listdescriptors`, and `listunspent` commands may now output
ACK 53d604079390b1f017ed296686ceddb859748bd7 Nit suggestions
81 | + 82 | +As more nodes that participate in relay and mining begin enabling 83 | +full-RBF, replacement of unconfirmed transactions by ones offering higher 84 | +fees may rapidly become more reliable. 85 | + 86 | +Members of this project strongly recommend that merchants and services
I think "Contributors to this project..." would be a better way for this sentence to start. I'm not sure what it really means to be a "member" of this project.
Indeed. Changed.
ACK 0ee1cfe94a1b735edc2581a05c4b12f8340ff609