From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 28 Oct 2026 08:55:52 -0700 Received: from mail-oa1-f64.google.com ([209.85.160.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1xM60C-0002VS-PV for bitcoindev@gnusha.org; Wed, 28 Oct 2026 08:55:52 -0700 Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-464fb819ac5sf1245893fac.1 for ; Wed, 28 Oct 2026 08:55:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20260707; t=1793202942; x=1793807742; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:message-id:to:from:date:sender:from:to:cc :subject:date:message-id:reply-to:content-type; bh=tztBnbLom7cK3TqZrd01guIlmmc41YtIDIT3uYimWws=; b=oECYzldhzqprawqoqgKKTKYetwlrXE8WInntvROnkxOTsbKrJ7w0YvsAr3EpDp0WO0 DhDWD96wq+L2syc1xpu+2qphf0dJGSdhFvUWODoPM3JEDIRCPjCpZ2/ZebDs/AiomhKv 2gfgByvGbAYwcLl3gq2ntVB0m07KoGS/Cpr2vKo1u9nrGmp32gaKnd10XwHP1vaoL/vD imOo2w8qME1L03EZ/OI4Dv7jjBN78LrOar8wOEPGoN873nf6nUC2eKC90m6fXOei5dK6 fOhyxDLPq17DBlb3gxagS+UnYMf3kdYUiOPwRXv9m2tUqifb3htPlx9HctOUonVH4Ahs EKBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20260707; t=1793202942; x=1793807742; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:message-id:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=tztBnbLom7cK3TqZrd01guIlmmc41YtIDIT3uYimWws=; b=QRmOECsAslXOVH2C6IPOAYKSPn4udXgsTfMklKYdjDAA+IN/GnW9qaNDDkmuAHI/kj oHTOxPHpYYrwFCim2omrs1wE5du9gOMHuvssfLcw7NQfcdg/K2igUGZ0nUlnPrR40FsO xwLAD/LtKo4ttzJRCBIacMq07RLpXcfk23hNDX5dk2wb6WqN4hBo2Zk1nxxrTdOeHxjZ duBrq9TeNLOCBsjWkaI/aJj5r4gwpg2404b36lSCe8AUGowWSwY3JslVR3XOJfWarRjf w5X4TcX9x748sTi6ehOmVfuxaYecyIJbo4nIv3+aQdB6NgaOiFn/5ca28uCXTNOs4Yov Utsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793202942; x=1793807742; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to:content-type; bh=tztBnbLom7cK3TqZrd01guIlmmc41YtIDIT3uYimWws=; b=hOw3whzdvXBvChrH/eyPN0ES1P/LhAN/qmrUgBiQ2tDJXzILKK3dDpdcnsQA0jfHZa fcEYyaXBmleIo1Eh7Dcp64HXcO8wPc+cNbLAAQvwgB9glBnpFCaxx6qwEh6GfWADi8Iv IGHbw22MoX5J82PZj+y7VtKpuZc2FEDIIBQd1UABecDO6FMZ+cFzGfje2imqYzfECOhl dzsYCqwD/cwo1R/e9qeaglnUnoW5W157le2b3gr3feZ+hfXihF377pQqILwbRHO4zzbf 1TlyNU98arIS/NxNhlx4aXnPdXzqIzzye9yEfBLbrmwXKOiahUEO9wiUBp1wEJ9sPzSm qLUQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AKwUvByO1WHMvktKUy8wnhnb8NaxQL2+Tz/KKILP9HfqSNMCYe2vRz+NiOw/6QtTOKXeo0+JTqEhLl+5sG/b@gnusha.org X-Gm-Message-State: AFq9FYKKddaDkQ2/81J/643ikpX2Mfg4Kerb3EW+689rXGerfZM1monp bl3UFZzRHIyA5LdiPMtLOHGNqBfIw4aeyCDdchBezDhvg/f7lb99jcGt X-Received: by 2002:a05:6870:c0ce:b0:4a7:4c9a:f458 with SMTP id 586e51a60fabf-4a8bb647c4bmr2125873fac.60.1793202942199; Wed, 28 Oct 2026 08:55:42 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdeG72ZPpIvTExfF8KzTQxmyuwjwocMqYAOLPVx/50k78Q==" Received: by 2002:a05:6870:c69d:b0:49d:f7b1:71ff with SMTP id 586e51a60fabf-4a8ba8cd32dls1583878fac.1.-pod-prod-03-us; Wed, 28 Oct 2026 08:55:35 -0700 (PDT) X-Received: by 2002:a05:6808:1202:b0:4b9:a8ac:47c with SMTP id 5614622812f47-56383d8eccamr1912145b6e.26.1793202935721; Wed, 28 Oct 2026 08:55:35 -0700 (PDT) Received: by 2002:a05:690c:a4d3:b0:8b0:7cd2:a7ee with SMTP id 00721157ae682-8b1b4c63931ms7b3; Wed, 28 Oct 2026 08:45:54 -0700 (PDT) X-Received: by 2002:a05:690c:660f:b0:8b0:a30a:7f2f with SMTP id 00721157ae682-8b1b5bd22e0mr18550197b3.33.1793202351741; Wed, 28 Oct 2026 08:45:51 -0700 (PDT) Date: Wed, 28 Oct 2026 08:45:51 -0700 (PDT) From: fanquake To: Bitcoin Development Mailing List Message-Id: Subject: [bitcoindev] Bitcoin Core v32.1 Released MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_160370_1640426554.1793202351449" X-Original-Sender: fanquake@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_160370_1640426554.1793202351449 Content-Type: multipart/alternative; boundary="----=_Part_160371_356545957.1793202351449" ------=_Part_160371_356545957.1793202351449 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Due to last-minute issues, 32.0, although tagged, was never fully announced or released. Bitcoin Core version 32.1 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: With the release of this new major version, versions 29.x and older are at "End of Life" and will no longer receive updates. In accordance with our [security=20 policy](https://bitcoincore.org/en/security-advisories/), any **easily=20 discoverable** vulnerabilities fixed in this release will be disclosed as soon as fixed releases are available for all= =20 maintained major versions. Under the regular disclosure schedule, we will disclose the following in=20 two weeks: * Medium and high severity vulnerabilities fixed in 30.0. There are 3 of=20 these. * Low severity vulnerabilities fixed in 32.1. There are 0 of these. 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=20 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=20 macOS) or `bin/` and `libexec/` (on Linux). Upgrading directly from a version of Bitcoin Core that has reached its EOL= =20 is possible, but it might take some time if the data directory needs to be=20 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 tested on the following operating systems or= =20 newer: Linux Kernel 3.17, macOS 14, and Windows 10 (version 1903). 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D P2P and network changes ----------------------- - Tor hidden services that are created automatically by Bitcoin Core will= =20 have [PoW=20 defenses](https://tpo.pages.torproject.net/onion-services/ecosystem/technol= ogy/security/pow/) enabled if the Tor daemon supports that. (#33414) - To reduce memory and CPU usage during periods of high transaction volume, rate-limiting of outgoing transaction relay has been changed to use a=20 global backlog instead of being done on a per-peer basis. The default rate-limit remains as 14 tx/s (boosted by 2.5x for outbound peers), though this can= =20 be changed via the `-txsendrate` configuration option. An additional=20 bandwidth rate-limit has also been introduced at 12MB of transactions per 10=20 minutes, with a high burst rate. The size of the global backlog and the token=20 bucket values for the rate limits can be queried via the `getnetworkinfo` RPC. (#34628) - Fix a possible leak of the originator's IP address for transactions sent= =20 with `sendrawtransaction` RPC when `-privatebroadcast=3D1`. When Bitcoin Core connects to a peer, if that peer has been advertised to support P2P=20 protocol v2, then Bitcoin Core tries to use the v2 protocol and if that fails it retries the connection using the v1 protocol. When the private broadcast= =20 is about to send a transaction to an IPv4 or IPv6 peer it overrides the=20 normal proxy selection and forces the connection through the Tor proxy (and thus through the Tor network, protecting the sender's IP address). However if= =20 v2 protocol is tried and it fails, then the v1 retry connection would be mad= e disregarding the "override proxy" request, possibly making an IPv4 or IPv= 6 direct connection. In other words, for this to happen the following must= =20 be true: 1. An IPv4 or IPv6 address has been advertised to the sender, indicating= =20 v2 support. 2. The sender must have Tor configured. 3. The sender's configuration must be such that connections to IPv4 or=20 IPv6 are made directly (no `-proxy=3D` is used for IPv4 or IPv6). 4. The recipient does not support v2 (the flags from 1. are bogus).=20 (#35410) - The private-broadcast queue (transactions submitted via=20 `sendrawtransaction` when `-privatebroadcast` is enabled and not yet echoed back from the=20 network) is now capped at 10,000 entries. When full, new submissions are rejected.= =20 It is up to the caller to inspect the queue via `getprivatebroadcastinfo` an= d free up space when stuck via `abortprivatebroadcast`. (#35406) - Each transaction sent via private broadcast (`-privatebroadcast`) is=20 limited to 1,000 send attempts. After reaching the limit, broadcasting stops; cal= l `sendrawtransaction` again to retry. Transactions that reach the limit=20 remain available through `getprivatebroadcastinfo` and `abortprivatebroadcast`. (#35680) - Support for the legacy ElGamal (type 0) encryption type when creating I2P sessions is being sunset by the I2P network and will be removed from=20 bitcoind on or before v34. Nodes using I2P with versions of Bitcoin Core earlier= =20 than v26.1 (PRs #29200, #29209) will soon only be able to connect to other=20 legacy ElGamal I2P peers and will be increasingly isolated from the rest of the network, with a reduced anonymity set. See #35696 for details. (#35696) - The project is currently considering whether to drop support for CJDNS=20 (see discussion in #36041). Since its introduction in v23.0, it has not gained substantial adoption amongst nodes, and there is some concern about=20 supporting a network with such a low number of peers. (#36202) - The CJDNS documentation was updated in #34811 to simplify the setup / pee= r discovery process. (#36202) - The default maximum number of automatic peer connections=20 (`-maxconnections`) has increased from 125 to 200, providing additional inbound capacity for block-relay-only peers. By default, transaction-relaying peers may use at= =20 most 50% of inbound connection slots. This percentage can be configured with= =20 the new `-inboundrelaypercent` option, which accepts values from 0 to 100 and defaults to 50. The number of automatic outbound connections is unchanged= . (#28463) - Explicitly configured `-maxconnections` values remain unchanged, but the= =20 new inbound transaction-relay limit still applies. To retain the previous connection limits, use `-maxconnections=3D125 -inboundrelaypercent=3D100`= . `-maxconnections` now clamps values above 2,000 with a warning to reduce crash risk at very high peer counts. (#35919) Mempool ------- - mempoolfullrbf=3D1 behaviour has been the default since v28 and the=20 argument has been removed since v29 subsequently. The `getmempoolinfo` RPC stops=20 returning the deprecated `fullrbf` key in the response unless the user requests it= =20 via the `-deprecatedrpc=3Dfullrbf` node argument. Also, the=20 `bip125-replaceable` key is removed from the mempool RPCs responses (because it, too, has been deprecated since v29) unless the user requests it via=20 `-deprecatedrpc=3Dbip125` node argument. Affected mempool RPCs are `getrawmempool`, `getmempoolancestors`, `getmempooldescendants`, and `getmempoolentry`. (#34911) Updated RPCs ------------ - `createpsbt`, `walletcreatefundedpsbt`, `converttopsbt`, and `psbtbumpfee= ` will now default to creating version 2 PSBTs. An optional `psbt_version` argument is added to these RPCs which allows specifying the version of=20 PSBT to create. (#21283) - 'taproot' has been removed from 'getdeploymentinfo' because its historica= l activation height is no longer used anywhere in the codebase. Application= s that rely on `deployments.taproot` to detect Taproot support should eithe= r assume Taproot to be always active (since Bitcoin Core v24.0), or check= =20 for `TAPROOT` in the `script_flags` array returned by `getdeploymentinfo`=20 (since Bitcoin Core v31.0). (#26201) - Bitcoin Core now reports a debug message explaining why transaction=20 inputs are non-standard. This information is now returned in the responses of the transaction-sending RPCs `submitpackage`, `sendrawtransaction`, and `testmempoolaccept`, and is also logged to `debug.log` (if `mempoolrej` + debug category is enabled) when such transactions are received over the= =20 P2P network. This does not change the existing error code `bad-txns-nonstandard-inputs`, but instead adds additional debug=20 information to it. (#29060) - The `dumptxoutset` RPC now supports writing to a named pipe on UNIX-like systems (see mkfifo(1) and mkfifo(3) man pages). This allows the raw UTXO= =20 set data to be consumed directly by another process (e.g., the `contrib/utxo-tools/utxo_to_sqlite.py` conversion script) without first writing it to disk. (#31560) - Mempool RPCs (`getrawmempool`, `getmempoolentry`, `testmempoolaccept`, `submitpackage`) now include an additional field `vsize_adjusted` (which= =20 is the sigop-adjusted virtual size used for policy) and `vsize_bip141` (whic= h represents the raw BIP141 virtual size). While `vsize` is marked as DEPRECATED, it was previously erroneously described as the BIP 141 vsize,= =20 but is actually sigops-adjusted vsize. Use `vsize_bip141` to actually get tha= t behavior or switch to the explicit `vsize_adjusted` for retained behavior= . (#32800) - `getrawtransaction` RPC now includes an additional field `vsize_adjusted`= , which is the sigop-adjusted virtual size if the transaction is in the=20 mempool. (#32800) - The `getblockchaininfo` RPC now exposes progress for background=20 validation if the `assumeutxo` feature is used. Once a node has synced from snapshot to= =20 tip, `verificationprogress` returns 1.0 and `initialblockdownload` false even though the node may still be validating blocks in the background. A new object, `backgroundvalidation`, provides details about the snapshot being validated, including snapshot height, number of blocks processed, best=20 block hash, chainwork, median time, and verification progress. (#33259) - `getbalances` now includes a `nonmempool` field under `mine`, reporting= =20 the net balance of wallet transactions that are not in the mempool (e.g. due= =20 to too low a feerate, too many unconfirmed ancestors, or a too-large=20 `OP_RETURN` output). This value is always negative, and is typically an over-estimate since it accounts for coins being spent but not for change outputs=20 returning to the wallet (which are also outside the mempool). Without this field,= =20 funds involved in non-mempool transactions could appear to go missing from the wallet balance. (#33671) - The `estimatesmartfee` RPC now combines two fee rate estimators: the=20 existing block policy fee rate estimator and a new mempool fee rate estimator.=20 (#34075) - The new mempool fee rate estimator produces conservative and economical= =20 fee rate estimates from the current contents of the mempool. It only produces= =20 a fee rate estimate when recent blocks indicate a healthy mempool, and fall= s back to the higher of the minimum relay fee rate and the current mempool minimum fee rate when the mempool is too sparse. Its statistics are=20 persisted to `fees/mempool_policy_estimator.dat` and reloaded on startup. `estimatesmartfee` returns the lower of the two fee rate estimators'=20 results, so the mempool fee rate estimator can only lower the block policy fee rat= e estimate. (#34075) - `estimatesmartfee` accepts an `options` object with `fee_rate_estimator`. Recognized values are `"auto"` (the default, combined behavior described above), `"block_policy"` (use only the block policy fee rate estimator),= =20 and `"mempool_policy"` (use only the mempool fee rate estimator). All unknown values are rejected. Users who want the previous behavior can select the block policy fee rate estimator explicitly. (#34075) - The options object also accepts `verbosity`. A verbosity of `2` or higher= =20 also returns `mempool_health_statistics`. (#34075) - When `fee_rate_estimator` is `"auto"` and the estimate succeeds, the=20 response also includes an `estimator` field identifying which fee rate estimator produced the result. (#34075) - Block policy fee estimator data is now stored in `fees/block_policy_estimates.dat`. If the new file does not exist, the=20 legacy `fee_estimates.dat` file is moved to the new path during startup. If both files exist, the legacy file is removed. (#34075) - Wallet fee rate estimation uses the default combined estimate. (#34075) - The `-deprecatedrpc=3Dstartingheight` configuration option has been=20 removed. The `getpeerinfo` RPC no longer returns the `startingheight` field, which was previously deprecated in v31.0. (#34796) - The `migratewallet` RPC now gives the option to not load the descriptor= =20 wallet after migrating it from a legacy wallet. This will now allow pruned nodes= =20 to migrate a wallet out of sync below the pruning height. Note that to use= =20 the new wallet it must be loaded to a full node anyway. (#35266) - The `getprivatebroadcastinfo` and `abortprivatebroadcast` RPCs now return= =20 an error `-32601`, "Method not found", when `-privatebroadcast` is not=20 enabled at startup. (#35267) - `gettransaction`, `listtransactions`, and `listsinceblock` now have an `alternate_wtxids` field which lists the wtxids of all transactions that= =20 have the same txid. When there is only one known witness variant the field is= =20 an empty array, analogous to `walletconflicts` and `mempoolconflicts`.=20 (#35501) - `getprivatebroadcastinfo` now reports an `attempts_remaining` field for= =20 each transaction. (#35680) - `getnetworkinfo` now reports the `asmap_version` if `-asmap` is in use.= =20 The version is the hash of the asmap data and can be verified against the=20 hash of the raw asmap data file that also gets attested in the [asmap-data](https://github.com/bitcoin-core/asmap-data) repository with `sha256sum`. (#36249) Changes to wallet related RPCs can be found in the Wallet section below. New RPCs -------- - A new `exportasmap` RPC writes the ASMap data embedded at build time to a file. (#33920) - A new `getopenrpcinfo` RPC returns a machine-readable OpenRPC 1.4.1 description of the RPCs available on the running node, including their parameters and result schemas. The new `rpc.discover` method provides the= =20 same public document using OpenRPC=E2=80=99s standard service discovery method= . To=20 include hidden commands and arguments, call `getopenrpcinfo` with=20 `show_hidden=3Dtrue`. (#34683) Build System ------------ - The next major release is planned to drop support for building Bitcoin=20 Core on Windows with MSVC, once clang-cl support is ready. See [#36153](https://github.com/bitcoin/bitcoin/issues/36153). - The undocumented `BITCOIN_GENBUILD_NO_GIT` environment variable is no=20 longer required and has been removed. The build system now automatically detects= =20 when it is being built from a source archive or as a subproject of a git-aware parent project and skips git metadata fetching. Users who need to disable= =20 git execution explicitly can still do so by configuring with `-DCMAKE_DISABLE_FIND_PACKAGE_Git=3DON`. (#32220) Updated settings ---------------- - The `bip125-replaceable` key in the wallet transaction RPCs such as `listtransactions`, `listsinceblock`, and `gettransaction` is marked as deprecated. Users still have the option to retrieve this key by passing= =20 the `-deprecatedrpc=3Dbip125` startup option. Also, the `-walletrbf` startup= =20 option has been marked as deprecated and will be fully removed in the next=20 release. Using this option emits a warning in the logs. (#34917) - The `libevent` logging category has been removed. Configurations like `-debug=3Dlibevent` or `-debugexclude=3Dlibevent` will log a deprecation= =20 warning and be ignored. These configurations will result in an error in a future release. - A new configuration option `-rpcmaxconnections` (default `16`) limits the number of simultaneously connected HTTP clients to the server. The=20 application will now attempt to reserve file descriptors for the HTTP server sockets.= =20 If your system has limited resources, consider using a lower setting. - A new `mining` logging category has been added, enabled with=20 `-debug=3Dmining`. The `CreateNewBlock(): block weight: ...` line, previously logged on ever= y block template build regardless of logging configuration, is now logged= =20 only when this category is enabled. `getblocktemplate` and Mining IPC users ar= e encouraged to enable it to see this log and future mining log. Changes to GUI or wallet related settings can be found in the GUI or Wallet= =20 section below. New settings ------------ - Block validation can now prefetch input prevouts from the chainstate=20 database in parallel while connecting blocks, speeding up validation when prevouts= =20 need to be read from disk. A new `-prevoutfetchthreads=3D` option controls = the number of prefetch worker threads. The default is 8 threads, up to a=20 maximum of 16; set it to 0 to disable parallel prefetching. (#35295) Tools and Utilities ------------------- - CLI -addrinfo now returns the full set of known addresses. In previous versions (v22.0 - v30.0) the set of returned addresses was filtered for quality and recency. This was changed since it does not match the logic= =20 for selecting peers to connect to, which does not filter. Note: CLI -addrinfo= =20 now requires bitcoind v26.0 or later, as it uses the getaddrmaninfo RPC internally. Users querying older, unmaintained node versions would need= =20 to use an older bitcoin-cli version. (#26988) - A new `bitcoin-util getchainparams` command returns hardcoded details=20 about the selected chain. (#35610) Wallet ------ - A new RPC `addhdkey` is added which allows a BIP 32 extended key to be=20 added to the wallet without needing to import it as part of a separate=20 descriptor. This key will not be used to produce any output scripts unless it is explicitly imported as part of a separate descriptor independent of the `addhdkey` RPC. (#29136) - A new `exportwatchonlywallet` RPC creates a watchonly wallet file from an existing descriptor wallet. The exported file contains the wallet's publi= c descriptors (with derived key caches where needed), transactions, and=20 address book data, but no private keys. It can be imported on another node using= =20 the existing `restorewallet` RPC. (#32489) - The [Offline Signing Tutorial](/doc/offline-signing-tutorial.md) has been updated to use `exportwatchonlywallet` for setting up the online=20 watch-only wallet, replacing the previous manual descriptor import workflow. (#32489= ) - A new `derivehdkey` RPC is available to obtain an xpub or xprv for a derivation path with at least one hardened step from an HD key known to= =20 the wallet. This can be used to coordinate a multisig setup, where each signe= r shares an xpub using a different derivation path than the default single-signature descriptors. The example in `doc/multisig-tutorial.md` i= s updated to use this RPC. (#32784) - The `fee_reason` field returned by wallet transaction creation RPCs now reports the reason the wallet selected the fee rate ("Fee Rate Estimator"= , "Mempool Min Fee", "User Specified Fee", "Fallback fee" or "Minimum Required Fee") instead of the block policy fee rate estimator's internal threshold details. Those details remain available in the block policy fee rate estimator debug log. (#34075) - Wallet names that are relative paths including `..` and `.` elements, and wallets named `/` are no longer allowed. Any users that depended on this behavior can instead use absolute paths to their wallet or move their=20 wallet to a safer path. (#34544) - The `send` and `sendall` RPCs are no longer marked as experimental.=20 (#35601) - The `fundrawtransaction` RPC no longer accepts a boolean as the second positional argument. This silent no-op fallback was removed and the=20 argument is now fully type checked. Passing a boolean will raise an error. (#35836= ) - On non-Windows systems, an authenticated RPC caller allowed to create=20 wallets could execute arbitrary commands as the node process account when `-walletnotify` was configured, by crafting a wallet name with regex replacement characters. Wallet notification placeholder replacement now= =20 treats wallet names literally. (#36048) - The `removeprunedfunds` RPC has been deprecated and will be removed in th= e next major release. In order to continue using it, `bitcoind` must be=20 started with the `-deprecatedrpc=3Dremoveprunedfunds` option. (#35605) GUI changes ----------- - A menu action has been added to allow creating a watchonly wallet file=20 from an existing descriptor wallet. This option mirrors the=20 `exportwatchonlywallet` RPC - the exported file can be imported to another node using the Restore Wallet menu action. (gui#872) - The "Enable Replace-By-Fee" checkbox has been removed from the Send tab,= =20 and the send confirmation dialog no longer states whether a transaction=20 signals BIP 125 replaceability. Transactions created in the GUI now follow the=20 wallet's `-walletrbf` setting, which defaults to signalling replaceability and is deprecated in this release (see Updated settings). (gui#936) - The migrate wallet option now allows to disable wallet loading after migrating. It is useful in case the node is pruned and the wallet was=20 created before the pruned height. (gui#953) - The GUI is now built with Qt 6.8.4. (#35709) Mining ------ - The IPC mining interface now rejects out-of-range block template options instead of silently clamping them, such as oversized reserved block=20 weight or coinbase sigops limits. (#33966) - The `-blockmaxweight` startup option is now rejected when it is lower tha= n `-blockreservedweight`, instead of being silently clamped. (#33966) IPC Interface ------------- - `BlockTemplate.submitSolution` now returns `reason` and `debug` rejection details in addition to the boolean result. Clients must regenerate IPC bindings from the updated `mining.capnp` schema to use the new method. Th= e previous `@7` method now returns an error directing clients to update. (#34672) - `BlockTemplate.submitSolution` now reports duplicate blocks as failures= =20 with `reason=3D"duplicate"`, matching `Mining.submitBlock`, instead of returni= ng success for duplicate submissions. (#34672) Logging ------- - BIP 9 bits 5 to 28 inclusive are now ignored for soft fork signaling, as= =20 per BIP 323. We won't warn about unknown deployments when receiving blocks=20 that set any of those bits in their version. (#34779) REST API -------- - REST responses now include `Cache-Control` headers to guide intermediary caches. Immutable responses such as block binary and hex data, block=20 parts, block filters, spent transaction outputs, and block-specific deployment= =20 info are marked cacheable for one day. Responses that can change with active= =20 chain or node state, as well as errors, are marked `no-store`. (#34794) Low-level changes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Indexes ------- - The transaction index (`-txindex`) now stores less data on disk; a fully rebuilt index takes less than half the space. The index is backwards compatible, so existing users will not see the space saving unless the=20 index is recreated. To do so, stop the node, delete the=20 `/indexes/txindex` directory, and restart; rebuilding can take up to a few hours depending o= n hardware. Progress can be monitored using the `getindexinfo` RPC. Once rebuilt, the index can no longer be read by previous releases, so=20 downgrading will rebuild it again in the old format. When downgrading permanently,=20 delete the `/indexes/txindex` directory first, since previous releases= =20 do not reclaim the space used by entries in the new format. (#35531) - The transaction output spender index (`-txospenderindex`) now uses less= =20 disk space. Existing indexes remain compatible and no action is required. To reclaim the space for data indexed before upgrading, stop the node,=20 delete the `/indexes/txospenderindex/` directory, and restart with `-txospenderindex` enabled to rebuild it. (#35634, #35568) RPC --- - Libevent has been replaced with a custom HTTP server (#35182). Certain=20 HTTP edge cases will observe different behavior to be more RFC-compliant: - Stricter enforcement of maximum headers size (8192 bytes) - Reject requests with whitespace in header field-names - "Line Folding" is rejected (whitespace at start of a header line) - Tolerate `%` at the end of requested URLs - Multiple "Content-Length" headers with different values are rejected - Clients attempting to connect from addresses not allowed by the=20 `-rpcallowip` option (or its default, `localhost`) will now be immediately disconnected instead of receiving a `403 Forbidden`. (#35592) Credits =3D=3D=3D=3D=3D=3D=3D Thanks to everyone who directly contributed to this release: - 0xb10c - Adam Andrews - Alexander Wiederin - Alfonso Roman Zubeldia - ameen-alam - amisha - Amiti Uttarwar - Andreas Kouloumos - Andrew Toth - Anthony Towns - Anthropic Security - Antoine Poinsot - ArvinFarrelP - Ava Chow - azuchi - benthecarman - Ben Woosley - Bicaru20 - b-l-u-e - Bortlesboat - Brandon Odiwuor - Bruno Garcia - CaesarCoder - Chandra Pratap - codeabysss - Cory Fields - Craig Raw - crStiv - csjones - cyb3ralbert - Daniela Brozzoni - Daniel Pfeifer - Danny van Heumen - David Gumberg - deadmanoz - dergoegge - ekzyis - Enoch Azariah - Eugene Siegel - Evan Sultanik - Fabian Jahr - fanquake - frankomosh - Gloria Zhao - Greg Sanders - Guillermo Fernandes - GuTS805 - Hao Xu - Hennadii Stepanov - Henry Romp - Hodlinator - HouseOfHufflepuff - ImMike - ismaelsadeeq - janb84 - jeanpablojp - Jean-Philippe Aumasson - joaonevess - Jon Atack - jpk68 - jrakibi - junbyjun1238 - Kanan - kevkevinpal - Kyle =F0=9F=90=86 - l0rinc - Laxman Acharya - littleyier - Luke Dashjr - maflcko - marcofleon - Martin Zumsande - Matias Furszyfer - Matthew Zipkin - Max Edwards - Mccalabrese - Memetic Money - Michael Dietz - Muhammad - Murch - Musa Haruna - naiyoma - nebula-21 - nervana21 - Novo - optout - Pablo Martin - Peter Zafonte - Philips Ucheolisah .N - Pieter Wuille - Pol Espinasa - pseudoramdom - pythcoiner - Renato Britto - rkrux - Rob Hamilton - Robin David - Roqqit - Ruslan Kasheparov - Russell Yanofsky - rustaceanrob - Sanjana2906 - satsfy - sayed nabhan - Sebastian Falbesoner - Sebastian van Staa - sedited - seduless - shaurya2k06 - Shrey - Shuvam Pandey - Sjors Provoost - stickies-v - stratospher - stringintech - taboger - takeshikurosawaa - Thomas - Torkel Rogstad - Vasil Dimov - vicjuma - ViniciusCestarii - w0xlt - Will Clark - winterrdog - xyzconstant - Yancy - yuvicc As well as to everyone that helped with translations on [Transifex](https://explore.transifex.com/bitcoin/bitcoin/). --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= c47ceea6-99de-41fe-a97c-928881963eccn%40googlegroups.com. ------=_Part_160371_356545957.1793202351449 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Due to last-minute issues, 32.0, although tagged, was never
fully anno= unced or released.

Bitcoin Core version 32.1 is now available fr= om:

=C2=A0 <https://bitcoincore.org/bin/bitcoin-core-32.1/>= ;

This release includes new features, various bug fixes and perf= ormance
improvements, as well as updated translations.

Plea= se report bugs using the issue tracker at GitHub:

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

To receive security a= nd update notifications, please subscribe to:

=C2=A0 <https:/= /bitcoincore.org/en/list/announcements/join/>

With the releas= e of this new major version, versions 29.x and
older are at "End of Li= fe" and will no longer receive updates.

In accordance with our [= security policy](https://bitcoincore.org/en/security-advisories/), any **ea= sily discoverable** vulnerabilities fixed in this
release will be disc= losed as soon as fixed releases are available for all maintained major vers= ions.

Under the regular disclosure schedule, we will disclose th= e following in two weeks:

* Medium and high severity vulnerabili= ties fixed in 30.0. There are 3 of these.

* Low severity vulnera= bilities fixed in 32.1. There are 0 of these.

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
installe= r (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on macOS)
or `bin/` and `libexec/` (on Linux).

Upgrading directly from a = version of Bitcoin Core that has reached its EOL is
possible, but it m= ight take some time if the data directory needs to be migrated. Old
wa= llet versions of Bitcoin Core are generally supported.

Compatibi= lity
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Bitcoin Cor= e is supported and tested on the following operating systems or newer:
Linux Kernel 3.17, macOS 14, and Windows 10 (version 1903). Bitcoin
C= ore should also work on most other Unix-like systems but is not as
fre= quently tested on them. It is not recommended to use Bitcoin Core on
u= nsupported systems.

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

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

- Tor hidden services that are created automatical= ly by Bitcoin Core will have
=C2=A0 [PoW defenses](https://tpo.pages.t= orproject.net/onion-services/ecosystem/technology/security/pow/)
=C2= =A0 enabled if the Tor daemon supports that. (#33414)
- To reduce memo= ry and CPU usage during periods of high transaction volume,
=C2=A0 rat= e-limiting of outgoing transaction relay has been changed to use a global=C2=A0 backlog instead of being done on a per-peer basis. The default r= ate-limit
=C2=A0 remains as 14 tx/s (boosted by 2.5x for outbound peer= s), though this can be
=C2=A0 changed via the `-txsendrate` configurat= ion option. An additional bandwidth
=C2=A0 rate-limit has also been in= troduced at 12MB of transactions per 10 minutes,
=C2=A0 with a high bu= rst rate. The size of the global backlog and the token bucket
=C2=A0 v= alues for the rate limits can be queried via the `getnetworkinfo` RPC.
=C2=A0 (#34628)
- Fix a possible leak of the originator's IP address = for transactions sent with
=C2=A0 `sendrawtransaction` RPC when `-priv= atebroadcast=3D1`. When Bitcoin Core
=C2=A0 connects to a peer, if tha= t peer has been advertised to support P2P protocol
=C2=A0 v2, then Bit= coin Core tries to use the v2 protocol and if that fails it
=C2=A0 ret= ries the connection using the v1 protocol. When the private broadcast is=C2=A0 about to send a transaction to an IPv4 or IPv6 peer it overrides = the normal
=C2=A0 proxy selection and forces the connection through th= e Tor proxy (and thus
=C2=A0 through the Tor network, protecting the s= ender's IP address). However if v2
=C2=A0 protocol is tried and it fai= ls, then the v1 retry connection would be made
=C2=A0 disregarding the= "override proxy" request, possibly making an IPv4 or IPv6
=C2=A0 dire= ct connection. In other words, for this to happen the following must be
=C2=A0 true:
=C2=A0 1. An IPv4 or IPv6 address has been advertised t= o the sender, indicating v2
=C2=A0 =C2=A0 =C2=A0support.
=C2=A0 2= . The sender must have Tor configured.
=C2=A0 3. The sender's configur= ation must be such that connections to IPv4 or IPv6
=C2=A0 =C2=A0 =C2= =A0are made directly (no `-proxy=3D` is used for IPv4 or IPv6).
=C2=A0= 4. The recipient does not support v2 (the flags from 1. are bogus). (#3541= 0)
- The private-broadcast queue (transactions submitted via `sendrawt= ransaction`
=C2=A0 when `-privatebroadcast` is enabled and not yet ech= oed back from the network)
=C2=A0 is now capped at 10,000 entries. Whe= n full, new submissions are rejected. It
=C2=A0 is up to the caller to= inspect the queue via `getprivatebroadcastinfo` and
=C2=A0 free up sp= ace when stuck via `abortprivatebroadcast`. (#35406)
- Each transactio= n sent via private broadcast (`-privatebroadcast`) is limited
=C2=A0 t= o 1,000 send attempts. After reaching the limit, broadcasting stops; call=C2=A0 `sendrawtransaction` again to retry. Transactions that reach the= limit remain
=C2=A0 available through `getprivatebroadcastinfo` and `= abortprivatebroadcast`.
=C2=A0 (#35680)
- Support for the legacy = ElGamal (type 0) encryption type when creating I2P
=C2=A0 sessions is = being sunset by the I2P network and will be removed from bitcoind
=C2= =A0 on or before v34. Nodes using I2P with versions of Bitcoin Core earlier= than
=C2=A0 v26.1 (PRs #29200, #29209) will soon only be able to conn= ect to other legacy
=C2=A0 ElGamal I2P peers and will be increasingly = isolated from the rest of the
=C2=A0 network, with a reduced anonymity= set. See #35696 for details. (#35696)
- The project is currently cons= idering whether to drop support for CJDNS (see
=C2=A0 discussion in #3= 6041). Since its introduction in v23.0, it has not gained
=C2=A0 subst= antial adoption amongst nodes, and there is some concern about supporting=C2=A0 a network with such a low number of peers. (#36202)
- The C= JDNS documentation was updated in #34811 to simplify the setup / peer
= =C2=A0 discovery process. (#36202)
- The default maximum number of aut= omatic peer connections (`-maxconnections`)
=C2=A0 has increased from = 125 to 200, providing additional inbound capacity for
=C2=A0 block-rel= ay-only peers. By default, transaction-relaying peers may use at most
= =C2=A0 50% of inbound connection slots. This percentage can be configured w= ith the
=C2=A0 new `-inboundrelaypercent` option, which accepts values= from 0 to 100 and
=C2=A0 defaults to 50. The number of automatic outb= ound connections is unchanged.
=C2=A0 (#28463)
- Explicitly confi= gured `-maxconnections` values remain unchanged, but the new
=C2=A0 in= bound transaction-relay limit still applies. To retain the previous
= =C2=A0 connection limits, use `-maxconnections=3D125 -inboundrelaypercent= =3D100`.
`-maxconnections` now clamps values above 2,000 with a warnin= g to reduce
=C2=A0 crash risk at very high peer counts. (#35919)
=
Mempool
-------

- mempoolfullrbf=3D1 behaviour has be= en the default since v28 and the argument has
=C2=A0 been removed sinc= e v29 subsequently. The `getmempoolinfo` RPC stops returning
=C2=A0 th= e deprecated `fullrbf` key in the response unless the user requests it via<= br />=C2=A0 the `-deprecatedrpc=3Dfullrbf` node argument. Also, the `bip125= -replaceable` key
=C2=A0 is removed from the mempool RPCs responses (b= ecause it, too, has been
=C2=A0 deprecated since v29) unless the user = requests it via `-deprecatedrpc=3Dbip125`
=C2=A0 node argument. Affect= ed mempool RPCs are `getrawmempool`,
=C2=A0 `getmempoolancestors`, `ge= tmempooldescendants`, and `getmempoolentry`.
=C2=A0 (#34911)

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

- `createpsbt`, `walletcreatefu= ndedpsbt`, `converttopsbt`, and `psbtbumpfee`
=C2=A0 will now default = to creating version 2 PSBTs. An optional `psbt_version`
=C2=A0 argumen= t is added to these RPCs which allows specifying the version of PSBT to
=C2=A0 create. (#21283)
- 'taproot' has been removed from 'getdeploy= mentinfo' because its historical
=C2=A0 activation height is no longer= used anywhere in the codebase. Applications
=C2=A0 that rely on `depl= oyments.taproot` to detect Taproot support should either
=C2=A0 assume= Taproot to be always active (since Bitcoin Core v24.0), or check for
= =C2=A0 `TAPROOT` in the `script_flags` array returned by `getdeploymentinfo= ` (since
=C2=A0 Bitcoin Core v31.0). (#26201)
- Bitcoin Core now = reports a debug message explaining why transaction inputs are
=C2=A0 n= on-standard. This information is now returned in the responses of the
= =C2=A0 transaction-sending RPCs `submitpackage`, `sendrawtransaction`, and<= br />=C2=A0 `testmempoolaccept`, and is also logged to `debug.log` (if `mem= poolrej` +
=C2=A0 debug category is enabled) when such transactions ar= e received over the P2P
=C2=A0 network. This does not change the exist= ing error code
=C2=A0 `bad-txns-nonstandard-inputs`, but instead adds = additional debug information
=C2=A0 to it. (#29060)
- The `dumptx= outset` RPC now supports writing to a named pipe on UNIX-like
=C2=A0 s= ystems (see mkfifo(1) and mkfifo(3) man pages). This allows the raw UTXO se= t
=C2=A0 data to be consumed directly by another process (e.g., the=C2=A0 `contrib/utxo-tools/utxo_to_sqlite.py` conversion script) without= first
=C2=A0 writing it to disk. (#31560)
- Mempool RPCs (`getra= wmempool`, `getmempoolentry`, `testmempoolaccept`,
=C2=A0 `submitpacka= ge`) now include an additional field `vsize_adjusted` (which is
=C2=A0= the sigop-adjusted virtual size used for policy) and `vsize_bip141` (which=
=C2=A0 represents the raw BIP141 virtual size). While `vsize` is mark= ed as
=C2=A0 DEPRECATED, it was previously erroneously described as th= e BIP 141 vsize, but
=C2=A0 is actually sigops-adjusted vsize. Use `vs= ize_bip141` to actually get that
=C2=A0 behavior or switch to the expl= icit `vsize_adjusted` for retained behavior.
=C2=A0 (#32800)
- `g= etrawtransaction` RPC now includes an additional field `vsize_adjusted`,=C2=A0 which is the sigop-adjusted virtual size if the transaction is in= the mempool.
=C2=A0 (#32800)
- The `getblockchaininfo` RPC now e= xposes progress for background validation if
=C2=A0 the `assumeutxo` f= eature is used. Once a node has synced from snapshot to tip,
=C2=A0 `v= erificationprogress` returns 1.0 and `initialblockdownload` false even
=C2=A0 though the node may still be validating blocks in the background. A= new
=C2=A0 object, `backgroundvalidation`, provides details about the= snapshot being
=C2=A0 validated, including snapshot height, number of= blocks processed, best block
=C2=A0 hash, chainwork, median time, and= verification progress. (#33259)
- `getbalances` now includes a `nonme= mpool` field under `mine`, reporting the
=C2=A0 net balance of wallet = transactions that are not in the mempool (e.g. due to
=C2=A0 too low a= feerate, too many unconfirmed ancestors, or a too-large `OP_RETURN`
= =C2=A0 output). This value is always negative, and is typically an over-est= imate
=C2=A0 since it accounts for coins being spent but not for chang= e outputs returning
=C2=A0 to the wallet (which are also outside the m= empool). Without this field, funds
=C2=A0 involved in non-mempool tran= sactions could appear to go missing from the
=C2=A0 wallet balance. (#= 33671)
- The `estimatesmartfee` RPC now combines two fee rate estimato= rs: the existing
=C2=A0 block policy fee rate estimator and a new memp= ool fee rate estimator. (#34075)
- The new mempool fee rate estimator = produces conservative and economical fee
=C2=A0 rate estimates from th= e current contents of the mempool. It only produces a
=C2=A0 fee rate = estimate when recent blocks indicate a healthy mempool, and falls
=C2= =A0 back to the higher of the minimum relay fee rate and the current mempoo= l
=C2=A0 minimum fee rate when the mempool is too sparse. Its statisti= cs are persisted
=C2=A0 to `fees/mempool_policy_estimator.dat` and rel= oaded on startup.
=C2=A0 `estimatesmartfee` returns the lower of the t= wo fee rate estimators' results,
=C2=A0 so the mempool fee rate estima= tor can only lower the block policy fee rate
=C2=A0 estimate. (#34075)=
- `estimatesmartfee` accepts an `options` object with `fee_rate_estim= ator`.
=C2=A0 Recognized values are `"auto"` (the default, combined be= havior described
=C2=A0 above), `"block_policy"` (use only the block p= olicy fee rate estimator), and
=C2=A0 `"mempool_policy"` (use only the= mempool fee rate estimator). All unknown
=C2=A0 values are rejected. = Users who want the previous behavior can
=C2=A0 select the block polic= y fee rate estimator explicitly. (#34075)
- The options object also ac= cepts `verbosity`. A verbosity of `2` or higher also
=C2=A0 returns `m= empool_health_statistics`. (#34075)
- When `fee_rate_estimator` is `"a= uto"` and the estimate succeeds, the response
=C2=A0 also includes an = `estimator` field identifying which fee rate estimator
=C2=A0 produced= the result. (#34075)
- Block policy fee estimator data is now stored = in
=C2=A0 `fees/block_policy_estimates.dat`. If the new file does not = exist, the legacy
=C2=A0 `fee_estimates.dat` file is moved to the new = path during startup. If both
=C2=A0 files exist, the legacy file is re= moved. (#34075)
- Wallet fee rate estimation uses the default combined= estimate. (#34075)

- The `-deprecatedrpc=3Dstartingheight` conf= iguration option has been removed. The
=C2=A0 `getpeerinfo` RPC no lon= ger returns the `startingheight` field, which was
=C2=A0 previously de= precated in v31.0. (#34796)
- The `migratewallet` RPC now gives the op= tion to not load the descriptor wallet
=C2=A0 after migrating it from = a legacy wallet. This will now allow pruned nodes to
=C2=A0 migrate a = wallet out of sync below the pruning height. Note that to use the
=C2= =A0 new wallet it must be loaded to a full node anyway. (#35266)
- The= `getprivatebroadcastinfo` and `abortprivatebroadcast` RPCs now return an=C2=A0 error `-32601`, "Method not found", when `-privatebroadcast` is = not enabled at
=C2=A0 startup. (#35267)
- `gettransaction`, `list= transactions`, and `listsinceblock` now have an
=C2=A0 `alternate_wtxi= ds` field which lists the wtxids of all transactions that have
=C2=A0 = the same txid. When there is only one known witness variant the field is an=
=C2=A0 empty array, analogous to `walletconflicts` and `mempoolconfli= cts`. (#35501)
- `getprivatebroadcastinfo` now reports an `attempts_re= maining` field for each
=C2=A0 transaction. (#35680)
- `getnetwor= kinfo` now reports the `asmap_version` if `-asmap` is in use. The
=C2= =A0 version is the hash of the asmap data and can be verified against the h= ash of
=C2=A0 the raw asmap data file that also gets attested in the=C2=A0 [asmap-data](https://github.com/bitcoin-core/asmap-data) reposit= ory with
=C2=A0 `sha256sum`. (#36249)

Changes to wallet rel= ated RPCs can be found in the Wallet section below.

New RPCs
--------

- A new `exportasmap` RPC writes the ASMap data embed= ded at build time to a
=C2=A0 file. (#33920)
- A new `getopenrpci= nfo` RPC returns a machine-readable OpenRPC 1.4.1
=C2=A0 description o= f the RPCs available on the running node, including their
=C2=A0 param= eters and result schemas. The new `rpc.discover` method provides the same=C2=A0 public document using OpenRPC=E2=80=99s standard service discove= ry method. To include
=C2=A0 hidden commands and arguments, call `geto= penrpcinfo` with `show_hidden=3Dtrue`.
=C2=A0 (#34683)

Buil= d System
------------

- The next major release is planned t= o drop support for building Bitcoin Core on
=C2=A0 Windows with MSVC, = once clang-cl support is ready. See
=C2=A0 [#36153](https://github.com= /bitcoin/bitcoin/issues/36153).
- The undocumented `BITCOIN_GENBUILD_N= O_GIT` environment variable is no longer
=C2=A0 required and has been = removed. The build system now automatically detects when
=C2=A0 it is = being built from a source archive or as a subproject of a git-aware
= =C2=A0 parent project and skips git metadata fetching. Users who need to di= sable git
=C2=A0 execution explicitly can still do so by configuring w= ith
=C2=A0 `-DCMAKE_DISABLE_FIND_PACKAGE_Git=3DON`. (#32220)

Updated settings
----------------

- The `bip125-replaceab= le` key in the wallet transaction RPCs such as
=C2=A0 `listtransaction= s`, `listsinceblock`, and `gettransaction` is marked as
=C2=A0 depreca= ted. Users still have the option to retrieve this key by passing the
= =C2=A0 `-deprecatedrpc=3Dbip125` startup option. Also, the `-walletrbf` sta= rtup option
=C2=A0 has been marked as deprecated and will be fully rem= oved in the next release.
=C2=A0 Using this option emits a warning in = the logs. (#34917)
- The `libevent` logging category has been removed.= Configurations like
=C2=A0 `-debug=3Dlibevent` or `-debugexclude=3Dli= bevent` will log a deprecation warning
=C2=A0 and be ignored. These co= nfigurations will result in an error in a future
=C2=A0 release.
= - A new configuration option `-rpcmaxconnections` (default `16`) limits the=
=C2=A0 number of simultaneously connected HTTP clients to the server.= The application
=C2=A0 will now attempt to reserve file descriptors f= or the HTTP server sockets. If
=C2=A0 your system has limited resource= s, consider using a lower setting.
- A new `mining` logging category h= as been added, enabled with `-debug=3Dmining`.
=C2=A0 The `CreateNewBl= ock(): block weight: ...` line, previously logged on every
=C2=A0 bloc= k template build regardless of logging configuration, is now logged only=C2=A0 when this category is enabled. `getblocktemplate` and Mining IPC = users are
=C2=A0 encouraged to enable it to see this log and future mi= ning log.

Changes to GUI or wallet related settings can be found= in the GUI or Wallet section below.

New settings
---------= ---

- Block validation can now prefetch input prevouts from the = chainstate database
=C2=A0 in parallel while connecting blocks, speedi= ng up validation when prevouts need
=C2=A0 to be read from disk. A new= `-prevoutfetchthreads=3D<n>` option controls the
=C2=A0 number = of prefetch worker threads. The default is 8 threads, up to a maximum
= =C2=A0 of 16; set it to 0 to disable parallel prefetching. (#35295)
Tools and Utilities
-------------------

- CLI -addrinfo= now returns the full set of known addresses. In previous
=C2=A0 versi= ons (v22.0 - v30.0) the set of returned addresses was filtered for
=C2= =A0 quality and recency. This was changed since it does not match the logic= for
=C2=A0 selecting peers to connect to, which does not filter. Note= : CLI -addrinfo now
=C2=A0 requires bitcoind v26.0 or later, as it use= s the getaddrmaninfo RPC
=C2=A0 internally. Users querying older, unma= intained node versions would need to use
=C2=A0 an older bitcoin-cli v= ersion. (#26988)
- A new `bitcoin-util getchainparams` command returns= hardcoded details about
=C2=A0 the selected chain. (#35610)

Wallet
------

- A new RPC `addhdkey` is added which allow= s a BIP 32 extended key to be added
=C2=A0 to the wallet without needi= ng to import it as part of a separate descriptor.
=C2=A0 This key will= not be used to produce any output scripts unless it is
=C2=A0 explici= tly imported as part of a separate descriptor independent of the
=C2= =A0 `addhdkey` RPC. (#29136)
- A new `exportwatchonlywallet` RPC creat= es a watchonly wallet file from an
=C2=A0 existing descriptor wallet. = The exported file contains the wallet's public
=C2=A0 descriptors (wit= h derived key caches where needed), transactions, and address
=C2=A0 b= ook data, but no private keys. It can be imported on another node using the=
=C2=A0 existing `restorewallet` RPC. (#32489)
- The [Offline Sig= ning Tutorial](/doc/offline-signing-tutorial.md) has been
=C2=A0 updat= ed to use `exportwatchonlywallet` for setting up the online watch-only
=C2=A0 wallet, replacing the previous manual descriptor import workflow. (= #32489)
- A new `derivehdkey` RPC is available to obtain an xpub or xp= rv for a
=C2=A0 derivation path with at least one hardened step from a= n HD key known to the
=C2=A0 wallet. This can be used to coordinate a = multisig setup, where each signer
=C2=A0 shares an xpub using a differ= ent derivation path than the default
=C2=A0 single-signature descripto= rs. The example in `doc/multisig-tutorial.md` is
=C2=A0 updated to use= this RPC. (#32784)
- The `fee_reason` field returned by wallet transa= ction creation RPCs now
=C2=A0 reports the reason the wallet selected = the fee rate ("Fee Rate Estimator",
=C2=A0 "Mempool Min Fee", "User Sp= ecified Fee", "Fallback fee" or
=C2=A0 "Minimum Required Fee") instead= of the block policy fee rate estimator's
=C2=A0 internal threshold de= tails. Those details remain available in the block
=C2=A0 policy fee r= ate estimator debug log. (#34075)
- Wallet names that are relative pat= hs including `..` and `.` elements, and
=C2=A0 wallets named `/` are n= o longer allowed. Any users that depended on this
=C2=A0 behavior can = instead use absolute paths to their wallet or move their wallet
=C2=A0= to a safer path. (#34544)
- The `send` and `sendall` RPCs are no long= er marked as experimental. (#35601)
- The `fundrawtransaction` RPC no = longer accepts a boolean as the second
=C2=A0 positional argument. Thi= s silent no-op fallback was removed and the argument
=C2=A0 is now ful= ly type checked. Passing a boolean will raise an error. (#35836)
- On = non-Windows systems, an authenticated RPC caller allowed to create wallets<= br />=C2=A0 could execute arbitrary commands as the node process account wh= en
=C2=A0 `-walletnotify` was configured, by crafting a wallet name wi= th regex
=C2=A0 replacement characters. Wallet notification placeholde= r replacement now treats
=C2=A0 wallet names literally. (#36048)
= - The `removeprunedfunds` RPC has been deprecated and will be removed in th= e
=C2=A0 next major release. In order to continue using it, `bitcoind`= must be started
=C2=A0 with the `-deprecatedrpc=3Dremoveprunedfunds` = option. (#35605)

GUI changes
-----------

- A men= u action has been added to allow creating a watchonly wallet file from an=C2=A0 existing descriptor wallet. This option mirrors the `exportwatch= onlywallet`
=C2=A0 RPC - the exported file can be imported to another = node using the Restore
=C2=A0 Wallet menu action. (gui#872)
- The= "Enable Replace-By-Fee" checkbox has been removed from the Send tab, and=C2=A0 the send confirmation dialog no longer states whether a transact= ion signals
=C2=A0 BIP 125 replaceability. Transactions created in the= GUI now follow the wallet's
=C2=A0 `-walletrbf` setting, which defaul= ts to signalling replaceability and is
=C2=A0 deprecated in this relea= se (see Updated settings). (gui#936)
- The migrate wallet option now a= llows to disable wallet loading after
=C2=A0 migrating. It is useful i= n case the node is pruned and the wallet was created
=C2=A0 before the= pruned height. (gui#953)
- The GUI is now built with Qt 6.8.4. (#3570= 9)

Mining
------

- The IPC mining interface now = rejects out-of-range block template options
=C2=A0 instead of silently= clamping them, such as oversized reserved block weight or
=C2=A0 coin= base sigops limits. (#33966)
- The `-blockmaxweight` startup option is= now rejected when it is lower than
=C2=A0 `-blockreservedweight`, ins= tead of being silently clamped. (#33966)


IPC Interface
-------------

- `BlockTemplate.submitSolution` now returns `re= ason` and `debug` rejection
=C2=A0 details in addition to the boolean = result. Clients must regenerate IPC
=C2=A0 bindings from the updated `= mining.capnp` schema to use the new method. The
=C2=A0 previous `@7` m= ethod now returns an error directing clients to update.
=C2=A0 (#34672= )
- `BlockTemplate.submitSolution` now reports duplicate blocks as fai= lures with
=C2=A0 `reason=3D"duplicate"`, matching `Mining.submitBlock= `, instead of returning
=C2=A0 success for duplicate submissions. (#34= 672)

Logging
-------

- BIP 9 bits 5 to 28 inclus= ive are now ignored for soft fork signaling, as per
=C2=A0 BIP 323. We= won't warn about unknown deployments when receiving blocks that
=C2= =A0 set any of those bits in their version. (#34779)

REST API--------

- REST responses now include `Cache-Control` headers= to guide intermediary
=C2=A0 caches. Immutable responses such as bloc= k binary and hex data, block parts,
=C2=A0 block filters, spent transa= ction outputs, and block-specific deployment info
=C2=A0 are marked ca= cheable for one day. Responses that can change with active chain
=C2= =A0 or node state, as well as errors, are marked `no-store`. (#34794)
=
Low-level changes
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

Indexes
-------

- The transaction index (= `-txindex`) now stores less data on disk; a fully
=C2=A0 rebuilt index= takes less than half the space. The index is backwards
=C2=A0 compati= ble, so existing users will not see the space saving unless the index
= =C2=A0 is recreated. To do so, stop the node, delete the `<datadir>/i= ndexes/txindex`
=C2=A0 directory, and restart; rebuilding can take up = to a few hours depending on
=C2=A0 hardware. Progress can be monitored= using the `getindexinfo` RPC. Once
=C2=A0 rebuilt, the index can no l= onger be read by previous releases, so downgrading
=C2=A0 will rebuild= it again in the old format. When downgrading permanently, delete
=C2= =A0 the `<datadir>/indexes/txindex` directory first, since previous r= eleases do
=C2=A0 not reclaim the space used by entries in the new for= mat. (#35531)
- The transaction output spender index (`-txospenderinde= x`) now uses less disk
=C2=A0 space. Existing indexes remain compatibl= e and no action is required. To
=C2=A0 reclaim the space for data inde= xed before upgrading, stop the node, delete the
=C2=A0 `<datadir>= ;/indexes/txospenderindex/` directory, and restart with
=C2=A0 `-txosp= enderindex` enabled to rebuild it. (#35634, #35568)

RPC
---=

- Libevent has been replaced with a custom HTTP server (#35182)= . Certain HTTP
=C2=A0 edge cases will observe different behavior to be= more RFC-compliant:
=C2=A0 - Stricter enforcement of maximum headers = size (8192 bytes)
=C2=A0 - Reject requests with whitespace in header f= ield-names
=C2=A0 - "Line Folding" is rejected (whitespace at start of= a header line)
=C2=A0 - Tolerate `%` at the end of requested URLs
=C2=A0 - Multiple "Content-Length" headers with different values are reje= cted
- Clients attempting to connect from addresses not allowed by the= `-rpcallowip`
=C2=A0 option (or its default, `localhost`) will now be= immediately disconnected
=C2=A0 instead of receiving a `403 Forbidden= `. (#35592)

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

Thanks= to everyone who directly contributed to this release:

- 0xb10c<= br />- Adam Andrews
- Alexander Wiederin
- Alfonso Roman Zubeldia=
- ameen-alam
- amisha
- Amiti Uttarwar
- Andreas Koulo= umos
- Andrew Toth
- Anthony Towns
- Anthropic Security
- Antoine Poinsot
- ArvinFarrelP
- Ava Chow
- azuchi
-= benthecarman
- Ben Woosley
- Bicaru20
- b-l-u-e
- Bort= lesboat
- Brandon Odiwuor
- Bruno Garcia
- CaesarCoder
= - Chandra Pratap
- codeabysss
- Cory Fields
- Craig Raw
- crStiv
- csjones
- cyb3ralbert
- Daniela Brozzoni
- = Daniel Pfeifer
- Danny van Heumen
- David Gumberg
- deadmano= z
- dergoegge
- ekzyis
- Enoch Azariah
- Eugene Siegel<= br />- Evan Sultanik
- Fabian Jahr
- fanquake
- frankomosh- Gloria Zhao
- Greg Sanders
- Guillermo Fernandes
- GuT= S805
- Hao Xu
- Hennadii Stepanov
- Henry Romp
- Hodlin= ator
- HouseOfHufflepuff
- ImMike
- ismaelsadeeq
- janb= 84
- jeanpablojp
- Jean-Philippe Aumasson
- joaonevess
= - Jon Atack
- jpk68
- jrakibi
- junbyjun1238
- Kanan- kevkevinpal
- Kyle =F0=9F=90=86
- l0rinc
- Laxman Achar= ya
- littleyier
- Luke Dashjr
- maflcko
- marcofleon- Martin Zumsande
- Matias Furszyfer
- Matthew Zipkin
- M= ax Edwards
- Mccalabrese
- Memetic Money
- Michael Dietz
- Muhammad
- Murch
- Musa Haruna
- naiyoma
- nebula-2= 1
- nervana21
- Novo
- optout
- Pablo Martin
- Pet= er Zafonte
- Philips Ucheolisah .N
- Pieter Wuille
- Pol Esp= inasa
- pseudoramdom
- pythcoiner
- Renato Britto
- rkr= ux
- Rob Hamilton
- Robin David
- Roqqit
- Ruslan Kashe= parov
- Russell Yanofsky
- rustaceanrob
- Sanjana2906
-= satsfy
- sayed nabhan
- Sebastian Falbesoner
- Sebastian va= n Staa
- sedited
- seduless
- shaurya2k06
- Shrey
= - Shuvam Pandey
- Sjors Provoost
- stickies-v
- stratospher<= br />- stringintech
- taboger
- takeshikurosawaa
- Thomas- Torkel Rogstad
- Vasil Dimov
- vicjuma
- ViniciusCestar= ii
- w0xlt
- Will Clark
- winterrdog
- xyzconstant
- Yancy
- yuvicc

As well as to everyone that helped with t= ranslations on
[Transifex](https://explore.transifex.com/bitcoin/bitco= in/).

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/c47ceea6-99de-41fe-a97c-928881963eccn%40googlegroups.com.
------=_Part_160371_356545957.1793202351449-- ------=_Part_160370_1640426554.1793202351449--