Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9A343C002D for ; Tue, 13 Dec 2022 12:07:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 5EFAF415F8 for ; Tue, 13 Dec 2022 12:07:05 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 5EFAF415F8 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=H5AxHbKs X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.848 X-Spam-Level: X-Spam-Status: No, score=-0.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_ABUSE_SURBL=1.25] autolearn=no autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k00zI8ZRAxlz for ; Tue, 13 Dec 2022 12:07:01 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 33BFE415F0 Received: from mail-ej1-x641.google.com (mail-ej1-x641.google.com [IPv6:2a00:1450:4864:20::641]) by smtp4.osuosl.org (Postfix) with ESMTPS id 33BFE415F0 for ; Tue, 13 Dec 2022 12:07:01 +0000 (UTC) Received: by mail-ej1-x641.google.com with SMTP id kw15so35927625ejc.10 for ; Tue, 13 Dec 2022 04:07:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=UV45LPrAXy6scRzB+hfqgNkRcSuSV/m+FMS7ovDiykg=; b=H5AxHbKs/7pQT1/6G4mYS5uNWdvnn+vqSn9NY1FMm4VdYJQxhlMmkITH0O6BL+2knC Qxz/ry4/ulNqyBQceCxixfLwaONiTgxj4V2istQ7lXy/f9fXRPj+wjpjeoeMmhgzkj4J DwJVCKHIGmHyrWjCQpz2o2Wi78lIW3LmMkSorGQDRq/2UQVRrr5UX8nSS7zsmz7aHJZY +VKZ0RFa4LXOqw7IIuSmA6jB2kex4n0mCJuOZh21jq9pCQgycgkuVygr6pKMRz8qe7kt 5K9W4W19uYeh1ov2jRSFh/rwvB4Trw/hkKLy/LAtYAipOCBU3NBgsfGwovOHqCl/ufAt D9bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=UV45LPrAXy6scRzB+hfqgNkRcSuSV/m+FMS7ovDiykg=; b=RRfAP5YOrIfqx2BDF9kv6/UGBUSL/1+EACTNQqdNp8r+TYUVRVqrvlwk3fn19KHkry h0YE3/kggeEzJWE1dhGlNMn5cPxNsyMy5+XETtOYqK17uFZ6qgD4azI2lIc4o0RX2Jza 23Hd9k7CuqgTg+y2dLX2/ZIxLmdwIpYN98BgAMUPisIUdF+CJGOPuQ/0ohf/l/nghmVq 4tAHYIP8U0TpZHJlJo3R9MRayIljO9aoAu1MZuxt8gQzVWZQTFQfAVDZE+M73oQbju+/ tIpZYbpVi0Y3ssZA0yp/Anjd7iZVw1St3ZV20EI3V/Od/Q9LBEpTzLPBzLRRvYSyhbvg K2qw== X-Gm-Message-State: ANoB5pndB2E5dasaFa1e70qXr8AvboOqCe7lvpDg5ZGUzpfjr3b0As1y cfvcaK3jsjPHlxmJecgvej1dWtFqOZFX3rAa58JIlukdBZdybZNq X-Google-Smtp-Source: AA0mqf6Dw9oLo/N9LPQGrcm664YKwUVdpgiaPf5eqELK3BIT/Wmext6e2BNTbifkVCXNsPnI4Z3Soif5DB3cbBFXBJo= X-Received: by 2002:a17:907:7782:b0:7b6:dd6d:b829 with SMTP id ky2-20020a170907778200b007b6dd6db829mr68868515ejc.602.1670933218360; Tue, 13 Dec 2022 04:06:58 -0800 (PST) MIME-Version: 1.0 From: Michael Ford Date: Tue, 13 Dec 2022 12:06:47 +0000 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="000000000000ec82dc05efb474bf" X-Mailman-Approved-At: Tue, 13 Dec 2022 13:07:59 +0000 Subject: [bitcoin-dev] Bitcoin Core 24.0.1 Released X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2022 12:07:05 -0000 --000000000000ec82dc05efb474bf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Due to last-minute issues (https://github.com/bitcoin/bitcoin/pull/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/ Or through BitTorrent: magnet:?xt=3Durn:btih:d7604a67c8ed6e3b35da15138f8ac81d7618788c&dn=3Dbitcoi= n-core-24.0.1&tr=3Dudp%3A%2F% 2Ftracker.openbittorrent.com%3A80&tr=3Dudp%3A%2F%2Ftracker.opentrackr.org %3A1337%2Fannounce&tr=3Dudp%3A%2F%2Ftracker.coppersurfer.tk %3A6969%2Fannounce&tr=3Dudp%3A%2F%2Ftracker.leechers-paradise.org %3A6969%2Fannounce&tr=3Dudp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=3Dudp= %3A%2F% 2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=3Dudp%3A%2F% 2Ftracker.bitcoin.sprovoost.nl%3A6969 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: To receive security and update notifications, please subscribe to: How to Upgrade =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D 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-transacti= ons [bip125]: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki Notable changes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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=3D0`. (#25355) Updated RPCs - - ------------ - - - The `-deprecatedrpc=3Dsoftforks` configuration option has been remove= d. The RPC `getblockchaininfo` no longer returns the `softforks` field, which wa= s previously deprecated in 23.0. (#23508) Information on soft fork status i= s now only available via the `getdeploymentinfo` RPC. - - - The `deprecatedrpc=3Dexclude_coinbase` configuration option has been removed. The `receivedby` RPCs (`listreceivedbyaddress`, `listreceivedbylabel`, `getreceivedbyaddress` and `getreceivedbylabel`) now always return result= s 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=3Dfees` configuration option has been removed. The top-level fee fields `fee`, `modifiedfee`, `ancestorfees` and `descendantfees` are no longer returned by RPCs `getmempoolentry`, `getrawmempool(verbose=3Dtrue)= `, `getmempoolancestors(verbose=3Dtrue)` and `getmempooldescendants(verbose=3Dtrue)`. 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 update= d 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/.?count=3D` instead of `GET /rest/headers//.` (deprecated) For `/blockfilterheaders/`, use `GET /rest/blockfilterheaders//.?count=3D<= COUNT=3D5>` instead of `GET /rest/blockfilterheaders///.` (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 th= e `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#migr= ating-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 `/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` setting= s 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=3Dvalue"). And th= ese settings can now be edited because `settings.json` values take precedence over `bitcoin.conf` values. (#15936) Low-level changes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D 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=C3=A8le Oul=C3=A8s - - - 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=C3=A3o 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=C3=A9phan 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/). -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEz7FuIclQ9n+pXlWPLuufXMCVJsEFAmOYaq4ACgkQLuufXMCV JsH8DQ/+PFPSLM3lOL2yZAHMlXuEKbG8at/H+pXDjwDcZsKs+cuF1Z3JfR6VmAX9 OB8tOvBbqJklZd6GlCeDs4XsBAdXppy50fdZSQ6Dqh7N/+nERUT8GEwTtU11sL7W vAVWhOmUn5fgCqOI/J2r4jjpZYMDys/NaCUYxmUF5Vm4JaJcs1JIfSUyHtQHdS6t VIdqb8D2+9mXM7qXbJ6OzF9KzrKFcujRHGPzcTnDvF3kOYKlpjT8w6bfFiBeuSeo G56X5CR61iXNU5W9HmHIKXBZv6Vnblc9cust7/5ESdgn6OMEnYghnaFSuMsWWAFd OKAGbuzunh+G9wMl1JWWG4sVVWLDtz6jNwwUu+1a0wrFryYPaPnq/JK09VL32xJr WKx6iNYqsEcno6kXfjSxLsQTIKzJw2T7iYaQCe8KTpYkaGitNzYMpEtFD68PU/gj 0LEf1sV+BgCuBR7hSBv31pse195Fd/wR71Yk4VVYx26u+82fIhK3ssyWxiiL6ycB K7FK9Q4QCt0QlO30oD/y/YQMuyVoVCf71qgp5ZB4TehwP+U4qYTp8wiCej7ta0rY vwjHbFZCYhzw05pIGE7bkbpGjdrnWK5ulaQztGAH6IXw0IPfsh9UJIr42VuXh1Nt AH6dVC+VwKsr/FjPHuFaj7lwyGw831bKiePptaQYPN9MEELqZqI=3D =3D5tAr -----END PGP SIGNATURE----- --000000000000ec82dc05efb474bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

= Due to last-minute issues (https://github.com/bitcoin/bitcoin/pull/26616),
24.0, alth= ough tagged, was never fully announced or released.

Bitcoin Core ver= sion 24.0.1 is now available from:

=C2=A0 https://bitcoincore.org/bin/bitcoin-core= -24.0.1/

Or through BitTorrent:


=C2=A0magnet:?xt=3Dur= n:btih:d7604a67c8ed6e3b35da15138f8ac81d7618788c&dn=3Dbitcoin-core-24.0.= 1&tr=3Dudp%3A%2F%
2F= tracker.openbittorrent.com%3A80&tr=3Dudp%3A%2F%2Ftracker.opentrackr.org
%3A1337%2Fannounce&= amp;tr=3Dudp%3A%2F%2Ftracker.c= oppersurfer.tk
%3A6969%2Fannounce&tr=3Dudp%3A%2F%2Ftracker.leechers-paradise.org
= %3A6969%2Fannounce&tr=3Dudp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&= tr=3Dudp%3A%2F%
2Ftracker.to= rrent.eu.org%3A451%2Fannounce&tr=3Dudp%3A%2F%
2Ftracker.bitcoin.sprovoost.nl%3A6969
This release includes new features, various bug fixes and performance=
improvements, as well as updated translations.

Please report bug= s using the issue tracker at GitHub:

=C2=A0 <https://github.com/bitcoin/bitcoin/issues= >

To receive security and update notifications, please subscr= ibe to:

=C2=A0 <https://bitcoincore.org/en/list/announcements/join/><= br>
How to Upgrade
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

= If you are running an older version, shut it down. Wait until it has
com= pletely
shut down (which might take a few minutes in some cases), then r= un the
installer (on Windows) or just copy over `/Applications/Bitcoin-Q= t` (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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Bi= tcoin Core is supported and extensively tested on operating systems
usin= g the Linux kernel, macOS 10.15+, and Windows 7 and newer.=C2=A0 BitcoinCore should also work on most other Unix-like systems but is not as
fre= quently tested on them.=C2=A0 It is not recommended to use Bitcoin Core on<= br>unsupported systems.

Notice of new option for transaction replace= ment policies
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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.=C2=A0 The option
defaults to the same policy = that was used in previous releases and no
changes to node policy will oc= cur 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 tr= ansaction acceptance
policy sometimes called "first-seen".
=
The Bitcoin Protocol does not, and cannot, provide any assurance thatthe first version of an unconfirmed transaction seen by a particular
n= ode will be the version that gets confirmed.=C2=A0 If there are multipleversions of the same unconfirmed transaction available, only the miner
= who includes one of those transactions in a block gets to decide which
v= ersion of the transaction gets confirmed.

Despite this lack of assur= ance, multiple merchants and services today
still make this assumption.<= br>
There are several benefits to users from removing this *first-seen*<= br>simplification.=C2=A0 One key benefit, the ability for the sender of atransaction to replace it with an alternative version paying higher
fe= es, was realized in [Bitcoin Core 0.12.0][] (February 2016) with the
int= roduction of [BIP125][] opt-in Replace By Fee (RBF).

Since then, the= re has been discussion about completely removing the
first-seen simplifi= cation and allowing users to replace any of their
older unconfirmed tran= sactions with newer transactions, a feature called
*full-RBF*.=C2=A0 Thi= s release includes a `mempoolfullrbf` configuration
option that allows e= nabling 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<= br>advocating for enabling full-RBF by default in a future version of
Bi= tcoin Core.

As more nodes that participate in relay and mining begin= enabling
full-RBF, replacement of unconfirmed transactions by ones offe= ring higher
fees may rapidly become more reliable.

Contributors t= o this project strongly recommend that merchants and services
not accept= unconfirmed transactions as final, and if they insist on doing
so,
t= o take the appropriate steps to ensure they have some recourse or plan for<= br>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/mast= er/bip-0125.mediawiki

Notable changes
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

P2P and network changes
- - ------------= -----------

- - - To address a potential denial-of-service, the logi= c to download headers
from peers
=C2=A0 has been reworked.=C2=A0 This= is particularly relevant for nodes starting up
for the
=C2=A0 first = time (or for nodes which are starting up after being offline for a
long = time).

=C2=A0 Whenever headers are received from a peer that have a = total chainwork
that is either
=C2=A0 less than the node's `-mini= mumchainwork` value or is sufficiently below
the work at
=C2=A0 the n= ode's tip, a "presync" phase will begin, in which the node wi= ll
download the
=C2=A0 peer's headers and verify the cumulative w= ork on the peer's chain, prior
to storing
=C2=A0 those headers pe= rmanently. Once that cumulative work is verified to be
sufficiently high= ,
=C2=A0 the headers will be redownloaded from that peer and fully valid= ated and
stored.

=C2=A0 This may result in initial headers sync t= aking longer for new nodes
starting up for
=C2=A0 the first time, bot= h because the headers will be downloaded twice, and
because the effect=C2=A0 of a peer disconnecting during the presync phase (or while the nod= e's
best headers chain has less
=C2=A0 than `-minimumchainwork`),= will result in the node needing to use the
headers presync mechanism=C2=A0 with the next peer as well (downloading the headers twice, again).<= br>(#25717)

- - - With I2P connections, a new, transient address is = used for each outbound
=C2=A0 connection if `-i2pacceptincoming=3D0`. (#= 25355)

Updated RPCs
- - ------------

- - - The `-deprecate= drpc=3Dsoftforks` configuration option has been removed.
The
=C2=A0 R= PC `getblockchaininfo` no longer returns the `softforks` field, which was=C2=A0 previously deprecated in 23.0. (#23508) Information on soft fork s= tatus is
=C2=A0 now only available via the `getdeploymentinfo` RPC.
<= br>- - - The `deprecatedrpc=3Dexclude_coinbase` configuration option has be= en
removed.
=C2=A0 The `receivedby` RPCs (`listreceivedbyaddress`, `l= istreceivedbylabel`,
=C2=A0 `getreceivedbyaddress` and `getreceivedbylab= el`) now always return results
=C2=A0 accounting for received coins from= coinbase outputs, without an option to
=C2=A0 change that behaviour. Ex= cluding coinbases was previously deprecated in
23.0.
=C2=A0 (#25171)<= br>
- - - The `deprecatedrpc=3Dfees` configuration option has been remov= ed. The
top-level
=C2=A0 fee fields `fee`, `modifiedfee`, `ancestorfe= es` and `descendantfees` are
no
=C2=A0 longer returned by RPCs `getme= mpoolentry`, `getrawmempool(verbose=3Dtrue)`,
=C2=A0 `getmempoolancestor= s(verbose=3Dtrue)` and
`getmempooldescendants(verbose=3Dtrue)`.
=C2= =A0 The same fee fields can be accessed through the `fees` object in theresult.
=C2=A0 The top-level fee fields were previously deprecated in 2= 3.0. (#25204)

- - - The `getpeerinfo` RPC has been updated with a ne= w `presynced_headers`
field,
=C2=A0 indicating the progress on the pr= esync phase mentioned in the
=C2=A0 "P2P and network changes" = section above.

Changes to wallet related RPCs can be found in the Wa= llet section below.

New RPCs
- - --------

- - - The `senda= ll` RPC spends specific UTXOs to one or more recipients
=C2=A0 without c= reating change. By default, the `sendall` RPC will spend
=C2=A0 every UT= XO in the wallet. `sendall` is useful to empty wallets or to
=C2=A0 crea= te a changeless payment from select UTXOs. When creating a payment
=C2= =A0 from a specific amount for which the recipient incurs the transaction=C2=A0 fee, continue to use the `subtractfeefromamount` option via the=C2=A0 `send`, `sendtoaddress`, or `sendmany` RPCs. (#24118)

- - - = A new `gettxspendingprevout` RPC has been added, which scans the
mempool= to find
=C2=A0 transactions spending any of the given outpoints. (#2440= 8)

- - - The `simulaterawtransaction` RPC iterates over the inputs a= nd outputs
of the given
=C2=A0 transactions, and tallies up the balan= ce change for the given wallet.
This can be
=C2=A0 useful e.g. when v= erifying that a coin join like transaction doesn't
contain unexpecte= d
=C2=A0 inputs that the wallet will then sign for unintentionally. (#22= 751)

Updated REST APIs
- - -----------------

- - - The `/h= eaders/` and `/blockfilterheaders/` endpoints have been updated
to use=C2=A0 a query parameter instead of path parameter to specify the result = count.
The
=C2=A0 count parameter is now optional, and defaults to 5 = for both endpoints.
The old
=C2=A0 endpoints are still functional, an= d have no documented behaviour change.

=C2=A0 For `/headers`, use=C2=A0 `GET /rest/headers/<BLOCK-HASH>.<bin|hex|json>?count=3D= <COUNT=3D5>`
=C2=A0 instead of
=C2=A0 `GET /rest/headers/<CO= UNT>/<BLOCK-HASH>.<bin|hex|json>` (deprecated)

=C2=A0= For `/blockfilterheaders/`, use
=C2=A0 `GET
/rest/blockfilterheaders= /<FILTERTYPE>/<BLOCK-HASH>.<bin|hex|json>?count=3D<COU= NT=3D5>`
=C2=A0 instead of
=C2=A0 `GET
/rest/blockfilterheaders= /<FILTERTYPE>/<COUNT>/<BLOCK-HASH>.<bin|hex|json>`<= br>(deprecated)

=C2=A0 (#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 m= empool
to
=C2=A0 accept transaction replacement without enforcing BIP= 125 replaceability
=C2=A0 signaling. (#25353)

Wallet
- - -----= -

- - - The `-walletrbf` startup option will now default to `true`. = The
=C2=A0 wallet will now default to opt-in RBF on transactions that it= creates.
(#25610)

- - - The `replaceable` option for the `create= rawtransaction` and
=C2=A0 `createpsbt` RPCs will now default to `true`.= Transactions created
=C2=A0 with these RPCs will default to having opt-= in RBF enabled. (#25610)

- - - The `wsh()` output descriptor was ext= ended with Miniscript support. You
can import Miniscript
=C2=A0 descr= iptors for P2WSH in a watchonly wallet to track coins, but you can'tspend from them using
=C2=A0 the Bitcoin Core wallet yet.
=C2=A0 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
=C2=A0 `sortedmulti_a()` functio= ns. (#24043)

- - - To help prevent fingerprinting transactions creat= ed by the Bitcoin Core
wallet, change output
=C2=A0 amounts are now r= andomized. (#24494)

- - - The `listtransactions`, `gettransaction`, = and `listsinceblock`
=C2=A0 RPC methods now include a wtxid field (hash = of serialized transaction,
=C2=A0 including witness data) for each trans= action. (#24198)

- - - The `listsinceblock`, `listtransactions` and = `gettransaction` output
now contain a new
=C2=A0 `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 f= ound
=C2=A0 in wallet" (-4), if the label is not in the address boo= k. (#25122)

Migrating Legacy Wallets to Descriptor Wallets
- - --= -------------------------------------------

An experimental RPC `mig= ratewallet` 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/mana= ging-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).

- - - Conf= iguration changes made in the bitcoin GUI (such as the pruning
setting,<= br>proxy settings, UPNP preferences) are now saved to `<datadir>/sett= ings.json`
file rather than to the Qt settings backend (windows registry= or unix
desktop
config files), so these settings will now apply to b= itcoind, instead of
being
ignored. (#15936, gui#602)

- - - Als= o, the interaction between GUI settings and `bitcoin.conf` settings
issimplified. Settings from `bitcoin.conf` are now displayed normally in th= e
GUI
settings dialog, instead of in a separate warning message (&quo= t;Options set in
this
dialog are overridden by the configuration file= : -setting=3Dvalue"). And these
settings can now be edited because = `settings.json` values take precedence
over
`bitcoin.conf` values. (#= 15936)

Low-level changes
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

RPC
- - ---

- - - The `deriveaddresses`, `get= descriptorinfo`, `importdescriptors` and
`scantxoutset` commands now
= =C2=A0 accept Miniscript expression within a `wsh()` descriptor. (#24148)
- - - The `getaddressinfo`, `decodescript`, `listdescriptors` and
= `listunspent` commands may now output
=C2=A0 a Miniscript descriptor ins= ide a `wsh()` where a `wsh(raw())` descriptor
was previously returned. (= #24148)

Credits
=3D=3D=3D=3D=3D=3D=3D

Thanks to everyone w= ho directly contributed to this release:

- - - /dev/fd0
- - - 0xb= 10c
- - - Adam Jonas
- - - akankshakashyap
- - - Ali Sherief
- = - - amadeuszpawlik
- - - Andreas Kouloumos
- - - Andrew Chow
- - -= Anthony Towns
- - - Antoine Poinsot
- - - Antoine Riard
- - - Aur= =C3=A8le Oul=C3=A8s
- - - avirgovi
- - - Ayush Sharma
- - - Baas- - - Ben Woosley
- - - BrokenProgrammer
- - - brunoerg
- - - br= ydinh
- - - Bushstar
- - - Calvin Kim
- - - CAnon
- - - Carl Do= ng
- - - chinggg
- - - Cory Fields
- - - Daniel Kraft
- - - Dan= iela Brozzoni
- - - darosior
- - - Dave Scotese
- - - David Bakin<= br>- - - dergoegge
- - - dhruv
- - - Dimitri
- - - dontbyte
- -= - Duncan Dean
- - - eugene
- - - Eunoia
- - - Fabian Jahr
- - = - furszy
- - - Gleb Naumenko
- - - glozow
- - - Greg Weber
- - = - Gregory Sanders
- - - gruve-p
- - - Hennadii Stepanov
- - - hiag= o
- - - Igor Bubelov
- - - ishaanam
- - - Jacob P.
- - - Jadi- - - James O'Beirne
- - - Janna
- - - Jarol Rodriguez
- - -= Jeremy Rand
- - - Jeremy Rubin
- - - jessebarton
- - - Jo=C3=A3o = Barbosa
- - - John Newbery
- - - Jon Atack
- - - Josiah Baker
-= - - Karl-Johan Alm
- - - KevinMusgrave
- - - Kiminuo
- - - klemen= ttan
- - - Kolby Moroz
- - - kouloumos
- - - Kristaps Kaupe
- -= - Larry Ruane
- - - Luke Dashjr
- - - MarcoFalke
- - - Marnix
= - - - Martin Leitner-Ankerl
- - - Martin Zumsande
- - - Michael Dietz=
- - - Michael Folkson
- - - Michael Ford
- - - Murch
- - - mut= atrum
- - - muxator
- - - Oskar Mendel
- - - Pablo Greco
- - - = pasta
- - - Patrick Strateman
- - - Pavol Rusnak
- - - Peter Bushn= ell
- - - phyBrackets
- - - Pieter Wuille
- - - practicalswift
= - - - randymcmillan
- - - Robert Spigler
- - - Russell Yanofsky
- = - - S3RK
- - - Samer Afach
- - - Sebastian Falbesoner
- - - Seibar= t Nedor
- - - Shashwat
- - - Sjors Provoost
- - - Smlep
- - - s= ogoagain
- - - Stacie
- - - St=C3=A9phan Vuylsteke
- - - Suhail Sa= qan
- - - Suhas Daftuar
- - - t-bast
- - - TakeshiMusgrave
- - = - Vasil Dimov
- - - W. J. van der Laan
- - - w0xlt
- - - whiteh0rs= e
- - - willcl-ark
- - - William Casarin
- - - Yancy Ribbens
As well as to everyone that helped with translations on
[Transifex](https://www.transifex.= com/bitcoin/bitcoin/).
-----BEGIN PGP SIGNATURE-----

iQIzBAEB= CAAdFiEEz7FuIclQ9n+pXlWPLuufXMCVJsEFAmOYaq4ACgkQLuufXMCV
JsH8DQ/+PFPSLM3= lOL2yZAHMlXuEKbG8at/H+pXDjwDcZsKs+cuF1Z3JfR6VmAX9
OB8tOvBbqJklZd6GlCeDs4= XsBAdXppy50fdZSQ6Dqh7N/+nERUT8GEwTtU11sL7W
vAVWhOmUn5fgCqOI/J2r4jjpZYMDy= s/NaCUYxmUF5Vm4JaJcs1JIfSUyHtQHdS6t
VIdqb8D2+9mXM7qXbJ6OzF9KzrKFcujRHGPz= cTnDvF3kOYKlpjT8w6bfFiBeuSeo
G56X5CR61iXNU5W9HmHIKXBZv6Vnblc9cust7/5ESdg= n6OMEnYghnaFSuMsWWAFd
OKAGbuzunh+G9wMl1JWWG4sVVWLDtz6jNwwUu+1a0wrFryYPaP= nq/JK09VL32xJr
WKx6iNYqsEcno6kXfjSxLsQTIKzJw2T7iYaQCe8KTpYkaGitNzYMpEtFD= 68PU/gj
0LEf1sV+BgCuBR7hSBv31pse195Fd/wR71Yk4VVYx26u+82fIhK3ssyWxiiL6ycB=
K7FK9Q4QCt0QlO30oD/y/YQMuyVoVCf71qgp5ZB4TehwP+U4qYTp8wiCej7ta0rY
vwj= HbFZCYhzw05pIGE7bkbpGjdrnWK5ulaQztGAH6IXw0IPfsh9UJIr42VuXh1Nt
AH6dVC+VwK= sr/FjPHuFaj7lwyGw831bKiePptaQYPN9MEELqZqI=3D
=3D5tAr
-----END PGP SIG= NATURE-----
--000000000000ec82dc05efb474bf--