From e24a25d882ba8c8dacc1eede6b9373fe7601f85b Mon Sep 17 00:00:00 2001 From: Ava Chow Date: Mon, 23 Sep 2024 13:02:28 -0400 Subject: [PATCH 1/6] test: Use shell builtins in run_command test case Github-Pull: bitcoin/bitcoin#30952 Rebased-From: 7bd3ee62f6d6f59ca599e85f81776d282dee1539 --- src/test/system_tests.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/test/system_tests.cpp b/src/test/system_tests.cpp index 07d15f5552..c9dd9c82cd 100644 --- a/src/test/system_tests.cpp +++ b/src/test/system_tests.cpp @@ -54,7 +54,7 @@ BOOST_AUTO_TEST_CASE(run_command) } { // Return non-zero exit code, with error message for stderr - const std::string command{"python3 -c 'import sys; print(\"err\", file=sys.stderr); sys.exit(2)'"}; + const std::string command{"sh -c 'echo err 1>&2 && false'"}; const std::string expected{"err"}; BOOST_CHECK_EXCEPTION(RunCommandParseJSON(command), std::runtime_error, [&](const std::runtime_error& e) { const std::string what(e.what()); From 7fcd7b85c64ffbcd67d8ff1add46d258b26b2029 Mon Sep 17 00:00:00 2001 From: Martin Zumsande Date: Tue, 24 Sep 2024 14:11:20 -0400 Subject: [PATCH 2/6] validation: Disable CheckForkWarningConditions for background chainstate The comparison of m_best_invalid with the tip of the respective chainstate makes no sense for the background chainstate, and can lead to incorrect error messages. Github-Pull: bitcoin/bitcoin#30962 Rebased-From: c0a0c72b4d68a4f0c53c2c4b95f4d6e399f8e4ee --- src/validation.cpp | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/validation.cpp b/src/validation.cpp index a6b7f3d361..59beb5cbda 100644 --- a/src/validation.cpp +++ b/src/validation.cpp @@ -2023,7 +2023,8 @@ void Chainstate::CheckForkWarningConditions() // Before we get past initial download, we cannot reliably alert about forks // (we assume we don't get stuck on a fork before finishing our initial sync) - if (m_chainman.IsInitialBlockDownload()) { + // Also not applicable to the background chainstate + if (m_chainman.IsInitialBlockDownload() || this->GetRole() == ChainstateRole::BACKGROUND) { return; } From 5feef9ce7ebf608e45aa9682512599494c0d46d8 Mon Sep 17 00:00:00 2001 From: Ava Chow Date: Tue, 24 Sep 2024 11:58:46 -0400 Subject: [PATCH 3/6] build: Bump to 28.0 --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 70fc37c5c5..c2bf42e39b 100644 --- a/configure.ac +++ b/configure.ac @@ -2,7 +2,7 @@ AC_PREREQ([2.69]) define(_CLIENT_VERSION_MAJOR, 28) define(_CLIENT_VERSION_MINOR, 0) define(_CLIENT_VERSION_BUILD, 0) -define(_CLIENT_VERSION_RC, 2) +define(_CLIENT_VERSION_RC, 0) define(_CLIENT_VERSION_IS_RELEASE, true) define(_COPYRIGHT_YEAR, 2024) define(_COPYRIGHT_HOLDERS,[The %s developers]) From 98745e03ffc9f69f901b827e19e4d8d645a27112 Mon Sep 17 00:00:00 2001 From: Ava Chow Date: Tue, 24 Sep 2024 12:04:49 -0400 Subject: [PATCH 4/6] doc: generate manpages --- doc/man/bitcoin-cli.1 | 6 +++--- doc/man/bitcoin-qt.1 | 6 +++--- doc/man/bitcoin-tx.1 | 6 +++--- doc/man/bitcoin-util.1 | 6 +++--- doc/man/bitcoin-wallet.1 | 6 +++--- doc/man/bitcoind.1 | 6 +++--- 6 files changed, 18 insertions(+), 18 deletions(-) diff --git a/doc/man/bitcoin-cli.1 b/doc/man/bitcoin-cli.1 index 969e03404e..f7d12ad2b4 100644 --- a/doc/man/bitcoin-cli.1 +++ b/doc/man/bitcoin-cli.1 @@ -1,7 +1,7 @@ .\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.49.3. -.TH BITCOIN-CLI "1" "September 2024" "bitcoin-cli v28.0.0rc2" "User Commands" +.TH BITCOIN-CLI "1" "September 2024" "bitcoin-cli v28.0.0" "User Commands" .SH NAME -bitcoin-cli \- manual page for bitcoin-cli v28.0.0rc2 +bitcoin-cli \- manual page for bitcoin-cli v28.0.0 .SH SYNOPSIS .B bitcoin-cli [\fI\,options\/\fR] \fI\, \/\fR[\fI\,params\/\fR] \fI\,Send command to Bitcoin Core\/\fR @@ -15,7 +15,7 @@ bitcoin-cli \- manual page for bitcoin-cli v28.0.0rc2 .B bitcoin-cli [\fI\,options\/\fR] \fI\,help Get help for a command\/\fR .SH DESCRIPTION -Bitcoin Core RPC client version v28.0.0rc2 +Bitcoin Core RPC client version v28.0.0 .SH OPTIONS .HP \-? diff --git a/doc/man/bitcoin-qt.1 b/doc/man/bitcoin-qt.1 index c3d03a97e9..ef92fe1223 100644 --- a/doc/man/bitcoin-qt.1 +++ b/doc/man/bitcoin-qt.1 @@ -1,12 +1,12 @@ .\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.49.3. -.TH BITCOIN-QT "1" "September 2024" "bitcoin-qt v28.0.0rc2" "User Commands" +.TH BITCOIN-QT "1" "September 2024" "bitcoin-qt v28.0.0" "User Commands" .SH NAME -bitcoin-qt \- manual page for bitcoin-qt v28.0.0rc2 +bitcoin-qt \- manual page for bitcoin-qt v28.0.0 .SH SYNOPSIS .B bitcoin-qt [\fI\,command-line options\/\fR] [\fI\,URI\/\fR] .SH DESCRIPTION -Bitcoin Core version v28.0.0rc2 +Bitcoin Core version v28.0.0 .PP Optional URI is a Bitcoin address in BIP21 URI format. .SH OPTIONS diff --git a/doc/man/bitcoin-tx.1 b/doc/man/bitcoin-tx.1 index c6e8585a38..3d57736665 100644 --- a/doc/man/bitcoin-tx.1 +++ b/doc/man/bitcoin-tx.1 @@ -1,7 +1,7 @@ .\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.49.3. -.TH BITCOIN-TX "1" "September 2024" "bitcoin-tx v28.0.0rc2" "User Commands" +.TH BITCOIN-TX "1" "September 2024" "bitcoin-tx v28.0.0" "User Commands" .SH NAME -bitcoin-tx \- manual page for bitcoin-tx v28.0.0rc2 +bitcoin-tx \- manual page for bitcoin-tx v28.0.0 .SH SYNOPSIS .B bitcoin-tx [\fI\,options\/\fR] \fI\, \/\fR[\fI\,commands\/\fR] \fI\,Update hex-encoded bitcoin transaction\/\fR @@ -9,7 +9,7 @@ bitcoin-tx \- manual page for bitcoin-tx v28.0.0rc2 .B bitcoin-tx [\fI\,options\/\fR] \fI\,-create \/\fR[\fI\,commands\/\fR] \fI\,Create hex-encoded bitcoin transaction\/\fR .SH DESCRIPTION -Bitcoin Core bitcoin\-tx utility version v28.0.0rc2 +Bitcoin Core bitcoin\-tx utility version v28.0.0 .SH OPTIONS .HP \-? diff --git a/doc/man/bitcoin-util.1 b/doc/man/bitcoin-util.1 index 5697b89244..e6045b671f 100644 --- a/doc/man/bitcoin-util.1 +++ b/doc/man/bitcoin-util.1 @@ -1,12 +1,12 @@ .\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.49.3. -.TH BITCOIN-UTIL "1" "September 2024" "bitcoin-util v28.0.0rc2" "User Commands" +.TH BITCOIN-UTIL "1" "September 2024" "bitcoin-util v28.0.0" "User Commands" .SH NAME -bitcoin-util \- manual page for bitcoin-util v28.0.0rc2 +bitcoin-util \- manual page for bitcoin-util v28.0.0 .SH SYNOPSIS .B bitcoin-util [\fI\,options\/\fR] [\fI\,commands\/\fR] \fI\,Do stuff\/\fR .SH DESCRIPTION -Bitcoin Core bitcoin\-util utility version v28.0.0rc2 +Bitcoin Core bitcoin\-util utility version v28.0.0 .SH OPTIONS .HP \-? diff --git a/doc/man/bitcoin-wallet.1 b/doc/man/bitcoin-wallet.1 index f6918203a7..23b3d47ae4 100644 --- a/doc/man/bitcoin-wallet.1 +++ b/doc/man/bitcoin-wallet.1 @@ -1,9 +1,9 @@ .\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.49.3. -.TH BITCOIN-WALLET "1" "September 2024" "bitcoin-wallet v28.0.0rc2" "User Commands" +.TH BITCOIN-WALLET "1" "September 2024" "bitcoin-wallet v28.0.0" "User Commands" .SH NAME -bitcoin-wallet \- manual page for bitcoin-wallet v28.0.0rc2 +bitcoin-wallet \- manual page for bitcoin-wallet v28.0.0 .SH DESCRIPTION -Bitcoin Core bitcoin\-wallet version v28.0.0rc2 +Bitcoin Core bitcoin\-wallet version v28.0.0 .PP bitcoin\-wallet is an offline tool for creating and interacting with Bitcoin Core wallet files. By default bitcoin\-wallet will act on wallets in the default mainnet wallet directory in the datadir. diff --git a/doc/man/bitcoind.1 b/doc/man/bitcoind.1 index db0ad0a21d..5fdcaa2ead 100644 --- a/doc/man/bitcoind.1 +++ b/doc/man/bitcoind.1 @@ -1,12 +1,12 @@ .\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.49.3. -.TH BITCOIND "1" "September 2024" "bitcoind v28.0.0rc2" "User Commands" +.TH BITCOIND "1" "September 2024" "bitcoind v28.0.0" "User Commands" .SH NAME -bitcoind \- manual page for bitcoind v28.0.0rc2 +bitcoind \- manual page for bitcoind v28.0.0 .SH SYNOPSIS .B bitcoind [\fI\,options\/\fR] \fI\,Start Bitcoin Core\/\fR .SH DESCRIPTION -Bitcoin Core version v28.0.0rc2 +Bitcoin Core version v28.0.0 .SH OPTIONS .HP \-? From 5de225f5c145368f70cb5f870933bcf9df6b92c8 Mon Sep 17 00:00:00 2001 From: Ava Chow Date: Mon, 30 Sep 2024 17:13:20 -0400 Subject: [PATCH 5/6] doc: 28.0 Release Notes --- doc/release-notes.md | 360 ++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 359 insertions(+), 1 deletion(-) diff --git a/doc/release-notes.md b/doc/release-notes.md index 7a587cfec9..3a151f8176 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -1 +1,359 @@ -See https://github.com/bitcoin-core/bitcoin-devwiki/wiki/28.0-Release-Notes-Draft +Bitcoin Core version 28.0 is now available from: + + + +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 +============== + +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. + +Running bitcoin core binaries on macOS requires self signing. +``` +cd /path/to/bitcoin-core/bin +xattr -d com.apple.quarantine bitcoin-cli bitcoin-qt bitcoin-tx bitcoin-util bitcoin-wallet bitcoind test_bitcoin +codesign -s - bitcoin-cli bitcoin-qt bitcoin-tx bitcoin-util bitcoin-wallet bitcoind test_bitcoin +``` + +Compatibility +============== + +Bitcoin Core is supported and extensively tested on operating systems +using the Linux Kernel 3.17+, macOS 11.0+, 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. + +Notable changes +=============== + +Testnet4/BIP94 support +----- + +Support for Testnet4 as specified in [BIP94](https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki) +has been added. The network can be selected with the `-testnet4` option and +the section header is also named `[testnet4]`. + +While the intention is to phase out support for Testnet3 in an upcoming +version, support for it is still available via the known options in this +release. + +Windows Data Directory +---------------------- + +The default data directory on Windows has been moved from `C:\Users\Username\AppData\Roaming\Bitcoin` +to `C:\Users\Username\AppData\Local\Bitcoin`. Bitcoin Core will check the existence +of the old directory first and continue to use that directory for backwards +compatibility if it is present. (#27064) + +P2P and network changes +----------------------- + +- Previously if Bitcoin Core was listening for P2P connections, either using + default settings or via `bind=addr:port` it would always also bind to + `127.0.0.1:8334` to listen for Tor connections. It was not possible to switch + this off, even if the node didn't use Tor. This has been changed and now + `bind=addr:port` results in binding on `addr:port` only. The default behavior + of binding to `0.0.0.0:8333` and `127.0.0.1:8334` has not been changed. + + If you are using a `bind=...` configuration without `bind=...=onion` and rely + on the previous implied behavior to accept incoming Tor connections at + `127.0.0.1:8334`, you need to now make this explicit by using + `bind=... bind=127.0.0.1:8334=onion`. (#22729) + +- Bitcoin Core will now fail to start up if any of its P2P binds fail, rather + than the previous behaviour where it would only abort startup if all P2P + binds had failed. (#22729) + +- UNIX domain sockets can now be used for proxy connections. Set `-onion` or `-proxy` +to the local socket path with the prefix `unix:` (e.g. `-onion=unix:/home/me/torsocket`). +(#27375) + +- unix socket paths are now accepted for `-zmqpubrawblock` and `-zmqpubrawtx` with +the format `-zmqpubrawtx=unix:/path/to/file` + +- Additional flags "in" and "out" have been added to `-whitelist` to control whether + permissions apply to incoming connections and/or manual (default: incoming only). + +- Transactions that are too low feerate will be opportunistically paired with their child +transactions and submitted as a package, thus enabling the node to download +1-parent-1-child packages using the existing transaction relay protocol. Combined with +other mempool policies, this allows limited "package relay" when a parent transaction +is below mempool minimum feerate; TRUC parents are additionally allowed to be below +minimum relay feerate (i.e. pay 0 fees). Use the `submitpackage` RPC to submit packages +directly to the node. Warning: this p2p feature is limited (unlike the `submitpackage` +interface, a child with multiple unconfirmed parents is not supported) and not yet +reliable under adversarial conditions. (#28970) + +Mempool Policy Changes +---------------------- + +- Transactions with version number set to 3 are now treated as standard on all networks (#29496), + subject to Opt-in Topologically Restricted Until Confirmation (TRUC) Transactions policy as + described in [BIP 431](https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki). The + policy includes limits on spending unconfirmed outputs (#28948), eviction of a previous descendant + if a more incentive-compatible one is submitted (#29306), and a maximum transaction size of 10,000vB + (#29873). These restrictions simplify the assessment of incentive compatibility of accepting or + replacing TRUC transactions, thus ensuring any replacements are more profitable for the node and + making fee-bumping more reliable. + +- Pay To Anchor (P2A) is a new standard witness output type for spending, + a newly recognised output template. This allows for key-less anchor + outputs, with compact spending conditions for additional efficiencies on + top of an equivalent `sh(OP_TRUE)` output, in addition to the txid stability + of the spending transaction. + N.B. propagation of this output spending on the network will be limited + until a sufficient number of nodes on the network adopt this upgrade. + +- Limited package RBF is now enabled, where the proposed conflicting package would result in + a connected component, aka cluster, of size 2 in the mempool. All clusters being conflicted + against must be of size 2 or lower. + +- `mempoolfullrbf=1` is now set by default. + +Updated RPCs +------------ + +- The JSON-RPC server now recognizes JSON-RPC 2.0 requests and responds with +strict adherence to the [specification](https://www.jsonrpc.org/specification). +See [JSON-RPC-interface.md](https://github.com/bitcoin/bitcoin/blob/master/doc/JSON-RPC-interface.md#json-rpc-11-vs-20) for details. + +- The `dumptxoutset` RPC now returns the UTXO set dump in a new and + improved format. At the same time the `loadtxoutset` RPC now + expects this new format in dumps it tries to load. Dumps with the + old format are no longer supported and need to be recreated using + the new format in order to be usable. + +- AssumeUTXO mainnet parameters have been added for height 840,000. + This means the `loadtxoutset` RPC can now be used on mainnet with + the matching UTXO set from that height. + +- The `warnings` field in `getblockchaininfo`, `getmininginfo` and + `getnetworkinfo` now returns all the active node warnings as an array + of strings, instead of just a single warning. The current behaviour + can temporarily be restored by running bitcoind with configuration + option `-deprecatedrpc=warnings`. + +- Previously when using the `sendrawtransaction` rpc and specifying outputs + that are already in the UXTO set an RPC error code `-27` with RPC error + text "Transaction already in block chain" was returned in response. + The help text has been updated to "Transaction outputs already in utxo set" + to more accurately describe the source of the issue. + +- The default mode for the `estimatesmartfee` RPC has been updated from `conservative` to `economical`. + which is expected to reduce overestimation for many users, particularly if Replace-by-Fee is an option. + For users that require high confidence in their fee estimates at the cost of potentially overestimating, + the `conservative` mode remains available. + +- An item of `unspents`, of `scantxoutset`, has two new fields: `blockhash` + and `confirmations`. `blockhash` is the hash of the block where the UTXO was + created. `confirmations` is the number of confirmations of the UTXO. (#30515) + +- `maxfeerate` and `maxburnamount` arguments are added to submitpackage. + +Changes to wallet related RPCs can be found in the Wallet section below. + +New RPCs +-------- + +Updated REST APIs +----------------- +- Parameter validation for `/rest/getutxos` has been improved by rejecting + truncated or overly large txids and malformed outpoint indices by raising an + HTTP_BAD_REQUEST "Parse error". Previously, these malformed requests would be + silently handled. (#30482, #30444) + +Build System +------------ + +- GCC 11.1 or later, or Clang 16.0 or later, +are now required to compile Bitcoin Core. + +- The minimum required glibc to run Bitcoin Core is now +2.31. This means that RHEL 8 and Ubuntu 18.04 (Bionic) +are no-longer supported. (#29987) + +- `--enable-lcov-branch-coverage` has been removed, given +incompatibilities between lcov version 1 & 2. `LCOV_OPTS` +should be used to set any options instead. + +Updated settings +---------------- + +- When running with `-alertnotify`, an alert can now be raised multiple +times instead of just once. Previously, it was only raised when unknown +new consensus rules were activated, whereas the scope has now been +increased to include all kernel warnings. Specifically, alerts will now +also be raised when an invalid chain with a large amount of work has +been detected. Additional warnings may be added in the future. +(#30058) + +Changes to GUI or wallet related settings can be found in the GUI or Wallet section below. + +New settings +------------ + +Tools and Utilities +------------------- + +Wallet +------ + +- The wallet now detects when wallet transactions conflict with the mempool. Mempool +conflicting transactions can be seen in the `"mempoolconflicts"` field of +`gettransaction`. The inputs of mempool conflicted transactions can now be respent +without manually abandoning the transactions when the parent transaction is dropped +from the mempool, which can cause wallet balances to appear higher. + +- A new `max_tx_weight` option has been added to the RPCs `fundrawtransaction`, `walletcreatefundedpsbt`, and `send`. +It specifies the maximum transaction weight. If the limit is exceeded during funding, the transaction will not be built. +The default value is 4,000,000 WU. + +- A new RPC `createwalletdescriptor` is added which allows users to add new automatically +generated descriptors to their wallet. This can be used to upgrade wallets created prior to +the introduction of a new standard descriptor, such as taproot. + +- A new RPC `gethdkeys` is added which will list all of the BIP 32 HD keys in use by all +of the descriptors in the wallet. These keys can be used in conjunction with `createwalletdescriptor` +to create and add single key descriptors to the wallet for a particular key that the wallet +already knows. + +- The `sendall` RPC can spend unconfirmed change and will include additional fees as necessary +for the resulting transaction to bump the unconfirmed transactions' feerates to the specified feerate. + +- If a `fee_rate` is specified when using the `bumpfee` RPC, the feerate is no longer restricted to +following the wallet's incremental feerate of 5 sat/vb. The feerate must still be at least the sum +of the original fee and the mempool's incremental feerate. + +GUI changes +----------- + +- The "Migrate Wallet" menu allows users to migrate any legacy wallet in their wallet +directory, regardless of the wallets loaded. (gui#824) + +- The "Information" window now displays the maximum mempool size along with the +mempool usage. (gui#825) + +Low-level changes +================= + +RPC +--- + +Tests +----- + +- The BIP94 timewarp attack mitigation is now active on the `regtest` network + +- `-testdatadir` is added to `test_bitcoin` to allow specifying the location for unit test data directories. + +Blockstorage +------------ + +- Block files are now XOR'd by default with a key stored in the blocksdir. +Previous releases of Bitcoin Core or previous external software will not be able to read the blocksdir with a non-zero XOR-key. +Refer to the `-blocksxor` help for more details. + +Credits +======= + +Thanks to everyone who directly contributed to this release: +- 0xb10c +- Alfonso Roman Zubeldia +- Andrew Toth +- AngusP +- Anthony Towns +- Antoine Poinsot +- Anton A +- Ava Chow +- Ayush Singh +- Ben Westgate +- Brandon Odiwuor +- brunoerg +- bstin +- Charlie +- Christopher Bergqvist +- Cory Fields +- crazeteam +- Daniela Brozzoni +- David Gumberg +- dergoegge +- Edil Medeiros +- Epic Curious +- Fabian Jahr +- fanquake +- furszy +- glozow +- Greg Sanders +- hanmz +- Hennadii Stepanov +- Hernan Marino +- Hodlinator +- ishaanam +- ismaelsadeeq +- Jadi +- Jon Atack +- josibake +- jrakibi +- kevkevin +- kevkevinpal +- Konstantin Akimov +- laanwj +- Larry Ruane +- Lőrinc +- Luis Schwab +- Luke Dashjr +- MarcoFalke +- marcofleon +- Marnix +- Martin Saposnic +- Martin Zumsande +- Matt Corallo +- Matthew Zipkin +- Matt Whitlock +- Max Edwards +- Michael Dietz +- Murch +- nanlour +- pablomartin4btc +- Peter Todd +- Pieter Wuille +- @RandyMcMillan +- RoboSchmied +- Roman Zeyde +- Ryan Ofsky +- Sebastian Falbesoner +- Sergi Delgado Segura +- Sjors Provoost +- spicyzboss +- StevenMia +- stickies-v +- stratospher +- Suhas Daftuar +- sunerok +- tdb3 +- TheCharlatan +- umiumi +- Vasil Dimov +- virtu +- willcl-ark + +As well as to everyone that helped with translations on +[Transifex](https://www.transifex.com/bitcoin/bitcoin/). From 89d34cffedcb6ec752fa2ca355ad32e1e413b2f0 Mon Sep 17 00:00:00 2001 From: Ava Chow Date: Fri, 4 Oct 2024 19:25:24 -0400 Subject: [PATCH 6/6] doc: Sync 28.0 release notes with website --- doc/release-notes.md | 204 +++++++++++++++++++++++-------------------- 1 file changed, 108 insertions(+), 96 deletions(-) diff --git a/doc/release-notes.md b/doc/release-notes.md index 3a151f8176..d9e6a34d0f 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -25,9 +25,9 @@ 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. -Running bitcoin core binaries on macOS requires self signing. +Running Bitcoin Core binaries on macOS requires self signing. ``` -cd /path/to/bitcoin-core/bin +cd /path/to/bitcoin-28.0/bin xattr -d com.apple.quarantine bitcoin-cli bitcoin-qt bitcoin-tx bitcoin-util bitcoin-wallet bitcoind test_bitcoin codesign -s - bitcoin-cli bitcoin-qt bitcoin-tx bitcoin-util bitcoin-wallet bitcoind test_bitcoin ``` @@ -37,7 +37,7 @@ Compatibility Bitcoin Core is supported and extensively tested on operating systems using the Linux Kernel 3.17+, macOS 11.0+, and Windows 7 and newer. Bitcoin -Core should also work on most other Unix-like systems but is not as +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. @@ -53,7 +53,7 @@ the section header is also named `[testnet4]`. While the intention is to phase out support for Testnet3 in an upcoming version, support for it is still available via the known options in this -release. +release. (#29775) Windows Data Directory ---------------------- @@ -63,7 +63,22 @@ to `C:\Users\Username\AppData\Local\Bitcoin`. Bitcoin Core will check the existe of the old directory first and continue to use that directory for backwards compatibility if it is present. (#27064) -P2P and network changes +JSON-RPC 2.0 Support +-------------------- + +The JSON-RPC server now recognizes JSON-RPC 2.0 requests and responds with +strict adherence to the [specification](https://www.jsonrpc.org/specification). +See [JSON-RPC-interface.md](https://github.com/bitcoin/bitcoin/blob/master/doc/JSON-RPC-interface.md#json-rpc-11-vs-20) for details. (#27101) + +JSON-RPC clients may need to be updated to be compatible with the JSON-RPC server. +Please open an issue on GitHub if any compatibility issues are found. + +libbitcoinconsensus Removal +--------------------------- + +The libbitcoin-consensus library was deprecated in 27.0 and is now completely removed. (#29648) + +P2P and Network Changes ----------------------- - Previously if Bitcoin Core was listening for P2P connections, either using @@ -83,30 +98,30 @@ P2P and network changes binds had failed. (#22729) - UNIX domain sockets can now be used for proxy connections. Set `-onion` or `-proxy` -to the local socket path with the prefix `unix:` (e.g. `-onion=unix:/home/me/torsocket`). -(#27375) + to the local socket path with the prefix `unix:` (e.g. `-onion=unix:/home/me/torsocket`). + (#27375) -- unix socket paths are now accepted for `-zmqpubrawblock` and `-zmqpubrawtx` with -the format `-zmqpubrawtx=unix:/path/to/file` +- UNIX socket paths are now accepted for `-zmqpubrawblock` and `-zmqpubrawtx` with + the format `-zmqpubrawtx=unix:/path/to/file` (#27679) -- Additional flags "in" and "out" have been added to `-whitelist` to control whether - permissions apply to incoming connections and/or manual (default: incoming only). +- Additional "in" and "out" flags have been added to `-whitelist` to control whether + permissions apply to inbound connections and/or manual ones (default: inbound only). (#27114) -- Transactions that are too low feerate will be opportunistically paired with their child -transactions and submitted as a package, thus enabling the node to download -1-parent-1-child packages using the existing transaction relay protocol. Combined with -other mempool policies, this allows limited "package relay" when a parent transaction -is below mempool minimum feerate; TRUC parents are additionally allowed to be below -minimum relay feerate (i.e. pay 0 fees). Use the `submitpackage` RPC to submit packages -directly to the node. Warning: this p2p feature is limited (unlike the `submitpackage` -interface, a child with multiple unconfirmed parents is not supported) and not yet -reliable under adversarial conditions. (#28970) +- Transactions having a feerate that is too low will be opportunistically paired with + their child transactions and submitted as a package, thus enabling the node to download + 1-parent-1-child packages using the existing transaction relay protocol. Combined with + other mempool policies, this change allows limited "package relay" when a parent transaction + is below the mempool minimum feerate. Topologically Restricted Until Confirmation (TRUC) + parents are additionally allowed to be below the minimum relay feerate (i.e., pay 0 fees). + Use the `submitpackage` RPC to submit packages directly to the node. Warning: this P2P + feature is limited (unlike the `submitpackage` interface, a child with multiple unconfirmed + parents is not supported) and not yet reliable under adversarial conditions. (#28970) Mempool Policy Changes ---------------------- - Transactions with version number set to 3 are now treated as standard on all networks (#29496), - subject to Opt-in Topologically Restricted Until Confirmation (TRUC) Transactions policy as + subject to opt-in Topologically Restricted Until Confirmation (TRUC) transaction policy as described in [BIP 431](https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki). The policy includes limits on spending unconfirmed outputs (#28948), eviction of a previous descendant if a more incentive-compatible one is submitted (#29306), and a maximum transaction size of 10,000vB @@ -120,71 +135,65 @@ Mempool Policy Changes top of an equivalent `sh(OP_TRUE)` output, in addition to the txid stability of the spending transaction. N.B. propagation of this output spending on the network will be limited - until a sufficient number of nodes on the network adopt this upgrade. + until a sufficient number of nodes on the network adopt this upgrade. (#30352) - Limited package RBF is now enabled, where the proposed conflicting package would result in a connected component, aka cluster, of size 2 in the mempool. All clusters being conflicted - against must be of size 2 or lower. + against must be of size 2 or lower. (#28984) -- `mempoolfullrbf=1` is now set by default. +- The default value of the `-mempoolfullrbf` configuration option has been changed from 0 to 1, + i.e. `mempoolfullrbf=1`. (#30493) Updated RPCs ------------ -- The JSON-RPC server now recognizes JSON-RPC 2.0 requests and responds with -strict adherence to the [specification](https://www.jsonrpc.org/specification). -See [JSON-RPC-interface.md](https://github.com/bitcoin/bitcoin/blob/master/doc/JSON-RPC-interface.md#json-rpc-11-vs-20) for details. - - The `dumptxoutset` RPC now returns the UTXO set dump in a new and - improved format. At the same time the `loadtxoutset` RPC now - expects this new format in dumps it tries to load. Dumps with the - old format are no longer supported and need to be recreated using - the new format in order to be usable. + improved format. Correspondingly, the `loadtxoutset` RPC now expects + this new format in the dumps it tries to load. Dumps with the old + format are no longer supported and need to be recreated using the + new format to be usable. (#29612) - AssumeUTXO mainnet parameters have been added for height 840,000. This means the `loadtxoutset` RPC can now be used on mainnet with - the matching UTXO set from that height. + the matching UTXO set from that height. (#28553) - The `warnings` field in `getblockchaininfo`, `getmininginfo` and `getnetworkinfo` now returns all the active node warnings as an array - of strings, instead of just a single warning. The current behaviour - can temporarily be restored by running bitcoind with configuration - option `-deprecatedrpc=warnings`. - -- Previously when using the `sendrawtransaction` rpc and specifying outputs - that are already in the UXTO set an RPC error code `-27` with RPC error - text "Transaction already in block chain" was returned in response. - The help text has been updated to "Transaction outputs already in utxo set" - to more accurately describe the source of the issue. + of strings, instead of a single warning. The current behaviour + can be temporarily restored by running Bitcoin Core with the configuration + option `-deprecatedrpc=warnings`. (#29845) -- The default mode for the `estimatesmartfee` RPC has been updated from `conservative` to `economical`. - which is expected to reduce overestimation for many users, particularly if Replace-by-Fee is an option. - For users that require high confidence in their fee estimates at the cost of potentially overestimating, - the `conservative` mode remains available. +- Previously when using the `sendrawtransaction` RPC and specifying outputs + that are already in the UTXO set, an RPC error code of `-27` with the + message "Transaction already in block chain" was returned in response. + The error message has been changed to "Transaction outputs already in utxo set" + to more accurately describe the source of the issue. (#30212) -- An item of `unspents`, of `scantxoutset`, has two new fields: `blockhash` - and `confirmations`. `blockhash` is the hash of the block where the UTXO was - created. `confirmations` is the number of confirmations of the UTXO. (#30515) +- The default mode for the `estimatesmartfee` RPC has been updated from `conservative` to `economical`, + which is expected to reduce over-estimation for many users, particularly if Replace-by-Fee is an option. + For users that require high confidence in their fee estimates at the cost of potentially over-estimating, + the `conservative` mode remains available. (#30275) -- `maxfeerate` and `maxburnamount` arguments are added to submitpackage. +- RPC `scantxoutset` now returns 2 new fields in the "unspents" JSON array: `blockhash` and `confirmations`. + See the scantxoutset help for details. (#30515) -Changes to wallet related RPCs can be found in the Wallet section below. +- RPC `submitpackage` now allows 2 new arguments to be passed: `maxfeerate` and `maxburnamount`. See the + subtmitpackage help for details. (#28950) -New RPCs --------- +Changes to wallet-related RPCs can be found in the Wallet section below. Updated REST APIs ----------------- - Parameter validation for `/rest/getutxos` has been improved by rejecting - truncated or overly large txids and malformed outpoint indices by raising an - HTTP_BAD_REQUEST "Parse error". Previously, these malformed requests would be - silently handled. (#30482, #30444) + truncated or overly large txids and malformed outpoint indices via raising + an HTTP_BAD_REQUEST "Parse error". These requests were previously handled + silently. (#30482, #30444) Build System ------------ - GCC 11.1 or later, or Clang 16.0 or later, -are now required to compile Bitcoin Core. +are now required to compile Bitcoin Core. (#29091, #30263) - The minimum required glibc to run Bitcoin Core is now 2.31. This means that RHEL 8 and Ubuntu 18.04 (Bionic) @@ -192,57 +201,49 @@ are no-longer supported. (#29987) - `--enable-lcov-branch-coverage` has been removed, given incompatibilities between lcov version 1 & 2. `LCOV_OPTS` -should be used to set any options instead. +should be used to set any options instead. (#30192) -Updated settings +Updated Settings ---------------- - When running with `-alertnotify`, an alert can now be raised multiple times instead of just once. Previously, it was only raised when unknown -new consensus rules were activated, whereas the scope has now been -increased to include all kernel warnings. Specifically, alerts will now -also be raised when an invalid chain with a large amount of work has -been detected. Additional warnings may be added in the future. -(#30058) +new consensus rules were activated. Its scope has now been increased to +include all kernel warnings. Specifically, alerts will now also be raised +when an invalid chain with a large amount of work has been detected. +Additional warnings may be added in the future. (#30058) Changes to GUI or wallet related settings can be found in the GUI or Wallet section below. -New settings ------------- - -Tools and Utilities -------------------- - Wallet ------ -- The wallet now detects when wallet transactions conflict with the mempool. Mempool -conflicting transactions can be seen in the `"mempoolconflicts"` field of -`gettransaction`. The inputs of mempool conflicted transactions can now be respent -without manually abandoning the transactions when the parent transaction is dropped -from the mempool, which can cause wallet balances to appear higher. +- The wallet now detects when wallet transactions conflict with the mempool. Mempool-conflicting + transactions can be seen in the `"mempoolconflicts"` field of `gettransaction`. The inputs + of mempool-conflicted transactions can now be respent without manually abandoning the + transactions when the parent transaction is dropped from the mempool, which can cause wallet + balances to appear higher. (#27307) - A new `max_tx_weight` option has been added to the RPCs `fundrawtransaction`, `walletcreatefundedpsbt`, and `send`. It specifies the maximum transaction weight. If the limit is exceeded during funding, the transaction will not be built. -The default value is 4,000,000 WU. +The default value is 4,000,000 WU. (#29523) -- A new RPC `createwalletdescriptor` is added which allows users to add new automatically -generated descriptors to their wallet. This can be used to upgrade wallets created prior to -the introduction of a new standard descriptor, such as taproot. +- A new `createwalletdescriptor` RPC allows users to add new automatically generated + descriptors to their wallet. This can be used to upgrade wallets created prior to the + introduction of a new standard descriptor, such as taproot. (#29130) -- A new RPC `gethdkeys` is added which will list all of the BIP 32 HD keys in use by all -of the descriptors in the wallet. These keys can be used in conjunction with `createwalletdescriptor` -to create and add single key descriptors to the wallet for a particular key that the wallet -already knows. +- A new RPC `gethdkeys` lists all of the BIP32 HD keys in use by all of the descriptors in the wallet. + These keys can be used in conjunction with `createwalletdescriptor` to create and add single key + descriptors to the wallet for a particular key that the wallet already knows. (#29130) -- The `sendall` RPC can spend unconfirmed change and will include additional fees as necessary -for the resulting transaction to bump the unconfirmed transactions' feerates to the specified feerate. +- The `sendall` RPC can now spend unconfirmed change and will include additional fees as necessary + for the resulting transaction to bump the unconfirmed transactions' feerates to the specified feerate. (#28979) -- If a `fee_rate` is specified when using the `bumpfee` RPC, the feerate is no longer restricted to -following the wallet's incremental feerate of 5 sat/vb. The feerate must still be at least the sum -of the original fee and the mempool's incremental feerate. +- In RPC `bumpfee`, if a `fee_rate` is specified, the feerate is no longer restricted + to following the wallet's incremental feerate of 5 sat/vb. The feerate must still be + at least the sum of the original fee and the mempool's incremental feerate. (#27969) -GUI changes +GUI Changes ----------- - The "Migrate Wallet" menu allows users to migrate any legacy wallet in their wallet @@ -251,25 +252,36 @@ directory, regardless of the wallets loaded. (gui#824) - The "Information" window now displays the maximum mempool size along with the mempool usage. (gui#825) -Low-level changes +Low-level Changes ================= -RPC ---- - Tests ----- -- The BIP94 timewarp attack mitigation is now active on the `regtest` network +- The BIP94 timewarp attack mitigation is now active on the `regtest` network. (#30681) -- `-testdatadir` is added to `test_bitcoin` to allow specifying the location for unit test data directories. +- A new `-testdatadir` option has been added to `test_bitcoin` to allow specifying the + location of unit test data directories. (#26564) Blockstorage ------------ - Block files are now XOR'd by default with a key stored in the blocksdir. Previous releases of Bitcoin Core or previous external software will not be able to read the blocksdir with a non-zero XOR-key. -Refer to the `-blocksxor` help for more details. +Refer to the `-blocksxor` help for more details. (#28052) + +Chainstate +---------- + +- The chainstate database flushes that occur when blocks are pruned will no longer +empty the database cache. The cache will remain populated longer, which significantly +reduces the time for initial block download to complete. (#28280) + +Dependencies +------------ + +- The dependency on Boost.Process has been replaced with cpp-subprocess, which is contained in source. +Builders will no longer need Boost.Process to build with external signer support. (#28981) Credits =======