Skip to content

Commit 0abb5b2

Browse files
committed
Merge bitcoin/bitcoin#26648: doc: move release notes to 24.0.1 and add notice
896fca1 doc: move release notes to 24.0.1 and add notice (fanquake) Pull request description: This mirrors what was done with 0.19.0.1. ACKs for top commit: instagibbs: ACK bitcoin/bitcoin@896fca1 gruve-p: ACK bitcoin/bitcoin@896fca1 w0xlt: ACK bitcoin/bitcoin@896fca1 Tree-SHA512: 590462555422c0f96895152d1a2f9f9cf0ebf2c61dc342094d747f4d48b878e5d91840b9c2ac6825bb7214239f035789f1765a907fb614017205377ed89631fd
2 parents 1ff7929 + 896fca1 commit 0abb5b2

File tree

2 files changed

+394
-387
lines changed

2 files changed

+394
-387
lines changed
Lines changed: 391 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,391 @@
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/).

0 commit comments

Comments
 (0)