From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 12 Oct 2025 04:43:54 -0700 Received: from mail-oa1-f61.google.com ([209.85.160.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1v7uUS-0005fz-LZ for bitcoindev@gnusha.org; Sun, 12 Oct 2025 04:43:54 -0700 Received: by mail-oa1-f61.google.com with SMTP id 586e51a60fabf-30cce8f9e59sf8467396fac.1 for ; Sun, 12 Oct 2025 04:43:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1760269426; x=1760874226; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=Vf48xZneVgmUk+Vy859nq28ABgR+ZxEeh+jVqOpVYFU=; b=gDjG8hyfzmuGlZFfrhhbabPcT5PY0FU72XRydY17H7r82O32z6oTdVYcJ8LkcC8WBP i18GH0Tbpq7Kn1Pqqywkl9Lz5e11se9rqRvzsQvGldyW611Vgq5REBFCXKLpAlq4I3m5 cFDNQskyn2OrZ6+j7hLdQT4hJggx/YnACkZFLqZoIVpjEXHCIKy17Pg2xaM9hje/2PS2 EVKKhlohcmI1IOXF5Ycsnc3UqowHUZSlkKfsCwbYFPaqjJzqEMvoYv5yRus6JeK86Be4 Bc0RnunoUDXoNY/EhnuAuml3yIGC/1vfpzFr/eEcUQ2Fg/vWid5G2YmYg6ha7w8QSJNh FJrw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760269426; x=1760874226; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=Vf48xZneVgmUk+Vy859nq28ABgR+ZxEeh+jVqOpVYFU=; b=cWQStoaIeQi4cq2RLwAPn1x0WaTG5AwW/+U8rqZQhX9P0huK1ucF6skNR6rTSktlFp nNpjq4yrM131EXSDPh59KaccbrmvgAbZ5Pgs5FSMnMLHAY9BbD2xr7cr0Chjj816FP02 0dDO8zmHeAli30rZxtnM+uwffrCOE82y0QDhgJ+F70ezkQ3AWy1cDcwiuOeKPtycMs5Y bRqMNkNdXNdV7swQsng+QypjqJaBaenT5hFf1AVvncBaleAMviCL+Vv4L99T/PJxjXyG 2TG2U77dyvivc/Vo5heWzTS4oTuAH/mLj8nj9135v6XM2byaoWLGNznv5PvinFCkRGs4 XdsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760269426; x=1760874226; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=Vf48xZneVgmUk+Vy859nq28ABgR+ZxEeh+jVqOpVYFU=; b=MEPNxXM+DnypRbdGddJZN3NuirRYEn7Nt02LNuNfALrzPmTI+TxbJXPagfexkM0oCZ hBFMJR75s55kSJAT/uN7CIUx3V0Do/8slRwATuRF+ajVgORwTTSKpQ+UviKQN5PFBWPC 4XhtdOc2xDyLziy3anucgTh8OM0K4mlAk8theDGAgGMIMwOh6ERUgpZu6y6aOdk9nEf0 tQmdiXDA/JouQJ0sYKHckHkCMdhdx/dBOESFfMpUM8G5O+sovS9edBkB3PMbD9WXk8Wq a05NY0kkwTxdVGMRgxdmIX2YRNy95Qw6BmeCyOnGzUex5dbdc9Ng7Wl9sI0dT3ITMvtF z+NQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUqyJD/lf7j6F7lWpt1lyzi6BMltxHlG5K0K2B/ZaTp/jY4IawLVVDeC99go/u1zH4756jLm5Nliunt@gnusha.org X-Gm-Message-State: AOJu0YySU0IaCHhwnh1sZrCTi90F15UzuHRUd1n1D7+z2L7nkbKVeJJc RQ8eagyGyl+vC2Zn3b4N4cVyzzDkxqUaYRXA9E0gd78WM0AbVr4+hz5K X-Google-Smtp-Source: AGHT+IHL1oROEtX6a8ZAnTxEXcm4wjhxFBJ4yly6hAtYmf5XvlKm2JLzrN41oGQpt6zlppITmB4PKA== X-Received: by 2002:a05:6870:3927:b0:370:faf6:be02 with SMTP id 586e51a60fabf-3c0f590d799mr8921046fac.2.1760269425851; Sun, 12 Oct 2025 04:43:45 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd6kSZRNN4vuv3t+7fPTM0VLPFgGr1i3/cBiurEsdazgFw==" Received: by 2002:a05:6870:5152:b0:368:a529:d5d9 with SMTP id 586e51a60fabf-3c7264d69acls1727621fac.2.-pod-prod-03-us; Sun, 12 Oct 2025 04:43:37 -0700 (PDT) X-Received: by 2002:a05:6808:280a:b0:441:bd1f:58e9 with SMTP id 5614622812f47-441bd1f77admr2829099b6e.56.1760269417810; Sun, 12 Oct 2025 04:43:37 -0700 (PDT) Received: by 2002:a05:690c:9310:b0:74f:1486:e2a9 with SMTP id 00721157ae682-78105e32872ms7b3; Sun, 12 Oct 2025 02:20:04 -0700 (PDT) X-Received: by 2002:a53:ab11:0:b0:635:4ecc:fc26 with SMTP id 956f58d0204a3-63ccb9617a0mr12423193d50.46.1760260803601; Sun, 12 Oct 2025 02:20:03 -0700 (PDT) Date: Sun, 12 Oct 2025 02:20:03 -0700 (PDT) From: fanquake To: Bitcoin Development Mailing List Message-Id: <715cfe5a-af73-48f5-a0d9-8b2f22ca6570n@googlegroups.com> Subject: [bitcoindev] Bitcoin Core v30.0 Released MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_307396_451024727.1760260803311" 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_307396_451024727.1760260803311 Content-Type: multipart/alternative; boundary="----=_Part_307397_1977598899.1760260803311" ------=_Part_307397_1977598899.1760260803311 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Bitcoin Core version 30.0 is now available from:=20 =20 This release includes new features, various bug fixes and performance=20 improvements, as well as updated translations.=20 Please report bugs using the issue tracker at GitHub:=20 =20 To receive security and update notifications, please subscribe to:=20 With the release of this new major version, versions `27.x` and older are at "Maintenance End" and will no longer receive updates. In accordance with the security policy, we will in two weeks disclose: * Medium and high severity vulnerabilities fixed in `28.0`. There are none= =20 of these. * Low severity vulnerabilities fixed in `30.0`. There are 5 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 `bitcoind`/`bitcoin-qt` (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 operating systems using the Linux Kernel 3.17+, macOS 13+, and Windows 10+. 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 Policy ------ - The maximum number of potentially executed legacy signature operations in= =20 a single standard transaction is now limited to 2500. Signature operations= =20 in all previous output scripts, in all input scripts, as well as all P2SH redeem scripts (if there are any) are counted toward the limit. The new limit is assumed to not affect any known typically formed standard transactions.= =20 The change was done to prepare for a possible BIP54 deployment in the future.= =20 (#32521) - `-datacarriersize` is increased to 100,000 by default, which effectively= =20 uncaps the limit (as the maximum transaction size limit will be hit first). It= =20 can be overridden with `-datacarriersize=3D83` to revert to the limit enforced i= n=20 previous versions. (#32406) - Multiple data carrier (OP_RETURN) outputs in a transaction are now=20 permitted for relay and mining. The `-datacarriersize` limit applies to the aggregate= =20 size of the scriptPubKeys across all such outputs in a transaction, not including= =20 the scriptPubKey size itself. (#32406) - The minimum block feerate (`-blockmintxfee`) has been changed to 0.001=20 satoshi per vB. It can still be changed using the configuration option. This option= =20 can be used by miners to set a minimum feerate on packages added to block templates.= =20 (#33106) - The default minimum relay feerate (`-minrelaytxfee`) and incremental=20 relay feerate (`-incrementalrelayfee`) have been changed to 0.1 satoshis per vB. They= =20 can still be changed using their respective configuration options, but it is=20 recommended to change both together if you decide to do so. (#33106) Other minimum feerates (e.g. the dust feerate, the minimum returned by=20 the fee estimator, and all feerates used by the wallet) remain unchanged. The=20 mempool minimum feerate still changes in response to high volume. Note that unless these lower defaults are widely adopted across the=20 network, transactions created with lower fee rates are not guaranteed to propagate or confirm.= =20 The wallet feerates remain unchanged; `-mintxfee` must be changed before attempting= =20 to create transactions with lower feerates using the wallet. (#33106) P2P and network changes ----------------------- - Opportunistic 1-parent-1-child package relay has been improved to handle situations when the child already has unconfirmed parent(s) in the=20 mempool. This means that 1p1c packages can be accepted and propagate, even if they= =20 are connected to broader topologies: multi-parent-1-child (where only 1 paren= t requires fee-bumping), grandparent-parent-child (where only parent=20 requires fee-bumping) etc. (#31385) - The transaction orphanage, which holds transactions with missing inputs= =20 temporarily while the node attempts to fetch its parents, now has improved Denial of= =20 Service protections. Previously, it enforced a maximum number of unique transactions (default= =20 100, configurable using `-maxorphantx`). Now, its limits are as follows: the= =20 number of entries (unique by wtxid and peer), plus each unique transaction's input= =20 count divided by 10, must not exceed 3,000. The total weight of unique transactions=20 must not exceed `404,000` Wu multiplied by the number of peers. (#31829) - The `-maxorphantx` option no longer has any effect, since the orphanage= =20 no longer limits the number of unique transactions. Users should remove this=20 configuration option if they were using it, as the setting will cause an error in=20 future versions when it is no longer recognized. (#31829) New `bitcoin` command --------------------- - A new `bitcoin` command line tool has been added to make features more=20 discoverable and convenient to use. The `bitcoin` tool just calls other executables=20 and does not implement any functionality on its own. Specifically `bitcoin node` is a= =20 synonym for `bitcoind`, `bitcoin gui` is a synonym for `bitcoin-qt`, and `bitcoin=20 rpc` is a synonym for `bitcoin-cli -named`. Other commands and options can be listed with= =20 `bitcoin help`. The new `bitcoin` command is an alternative to calling other commands=20 directly, but it doesn't replace them, and there are no plans to deprecate existing=20 commands. (#31375) External Signing ---------------- - Support for external signing on Windows has been re-enabled. (#29868) IPC Mining Interface -------------------- - The new `bitcoin` command does support one new feature: an (experimental)= =20 IPC Mining Interface that allows the node to work with Stratum v2 or other mining=20 client software, see (#31098). When the node is started with `bitcoin -m node=20 -ipcbind=3Dunix` it will listen on a unix socket for IPC client connections, allowing clients to= =20 request block templates and submit mined blocks. The `-m` option launches a new=20 internal binary (`bitcoin-node` instead of `bitcoind`) and is currently required but will= =20 become optional in the future (with #33229). - IPC connectivity introduces new dependencies (see=20 [multiprocess.md](https://github.com/bitcoin/bitcoin/blob/master/doc/multip= rocess.md)), which can be turned off with the `-DENABLE_IPC=3DOFF` build option if you= =20 do not intend to use IPC. (#31802) Install changes --------------- - The `test_bitcoin` executable is now installed in `libexec/` instead of= =20 `bin/`. It can still be executed directly, or accessed through the new `bitcoin`= =20 command as `bitcoin test`. The `libexec/` directory also contains new=20 `bitcoin-node` and `bitcoin-gui` binaries which support IPC features and are called through= =20 the `bitcoin` tool. In source builds only, `test_bitcoin-qt`,=20 `bench_bitcoin`, and `bitcoin-chainstate` are also now installed to `libexec/` instead of=20 `bin/` and can be accessed through the new `bitcoin` command. See `bitcoin help`=20 output for details. (#31679) - On Windows, the installer no longer adds a =E2=80=9C(64-bit)=E2=80=9D suf= fix to entries=20 in the Start Menu (#32132), and it now automatically removes obsolete artifacts= =20 during upgrades (#33422). Indexes ------- - The implementation of coinstatsindex was changed to prevent an overflow= =20 bug that could already be observed on the default Signet. The new version of the= =20 index will need to be synced from scratch when starting the upgraded node for the=20 first time. The new version is stored in `/indexes/coinstatsindex/` in contrast to=20 the old version which was stored at `/indexes/coinstats/`. The old version of the index= =20 is not deleted by the upgraded node in case the user chooses to downgrade their node in= =20 the future. If the user does not plan to downgrade it is safe for them to remove=20 `/indexes/coinstats/` from their datadir. A future release of Bitcoin Core may remove the old= =20 version of the index automatically. (#30469) Logging ------- - Unconditional logging to disk is now rate limited by giving each source= =20 location a quota of 1MiB per hour. Unconditional logging is any logging with a log= =20 level higher than debug, that is `info`, `warning`, and `error`. All logs will= =20 be prefixed with `[*]` if there is at least one source location that is=20 currently being suppressed. (#32604) - When `-logsourcelocations` is enabled, the log output now contains the=20 entire function signature instead of just the function name. (#32604) Updated RPCs ------------ - The `-paytxfee` startup option and the `settxfee` RPC are now deprecated= =20 and will be removed in Bitcoin Core 31.0. They allowed the user to set a=20 static fee rate for wallet transactions, which could potentially lead to overpaying= =20 or underpaying. Users should instead rely on fee estimation or specify a fee rate per=20 transaction using the `fee_rate` argument in RPCs such as `fundrawtransaction`,=20 `sendtoaddress`, `send`, `sendall`, and `sendmany`. (#31278) - Any RPC in which one of the parameters is a descriptor will throw an erro= r if the provided descriptor contains a whitespace at the beginning or the= =20 end of the public key within a fragment - e.g. `pk( KEY)` or `pk(KEY )`.=20 (#31603) - The `submitpackage` RPC, which allows submissions of child-with-parents packages, no longer requires that all unconfirmed parents be present. The package may contain other in-mempool ancestors as well. (#31385) - The `waitfornewblock` RPC now takes an optional `current_tip` argument. I= t is also no longer hidden. (#30635) - The `waitforblock` and `waitforblockheight` RPCs are no longer hidden.=20 (#30635) - The `psbtbumpfee` and `bumpfee` RPCs allow a replacement under fullrbf=20 and no longer require BIP-125 signalling. (#31953) - Transaction Script validation errors used to return the reason for the=20 error prefixed by either `mandatory-script-verify-flag-failed` if it was a=20 consensus error, or `non-mandatory-script-verify-flag` (without "-failed") if it=20 was a standardness error. This has been changed to=20 `block-script-verify-flag-failed` and `mempool-script-verify-flag-failed` for all block and mempool errors respectively. (#33183) - The `getmininginfo` RPC now returns "blockmintxfee" result specifying the= =20 value of `-blockmintxfee` configuration. (#33189) - The `getmempoolinfo` RPC now returns an additional "permitbaremultisig"= =20 and "maxdatacarriersize" field, reflecting the `-permitbaremultisig` and=20 `-datacarriersize` config values. (#29954) Changes to wallet-related RPCs can be found in the Wallet section below. New RPCs -------- - A new REST API endpoint (`/rest/spenttxouts/BLOCKHASH`) has been=20 introduced for efficiently fetching spent transaction outputs using the block's undo=20 data (#32540). Build System ------------ Updated settings ---------------- - The `-maxmempool` and `-dbcache` startup parameters are now capped on=20 32-bit systems to 500MB and 1GiB respectively. (#32530) - The `-natpmp` option is now set to `1` by default. This means nodes with= =20 `-listen` enabled (the default) but running behind a firewall, such as a local=20 network router, will be reachable if the firewall/router supports any of the `PCP` or=20 `NAT-PMP` protocols. (#33004) - The `-upnp` setting has now been fully removed. Use `-natpmp` instead.=20 (#32500) - Previously, `-proxy` specified the proxy for all networks (except I2P=20 which uses `-i2psam`) and only the Tor proxy could have been specified=20 separately via `-onion`. Now, the syntax of `-proxy` has been extended and it is=20 possible to specify separately the proxy for IPv4, IPv6, Tor and CJDNS by=20 appending `=3D` followed by the network name, for example `-proxy=3D127.0.0.1:5555=3Dipv6= ` configures a proxy only for IPv6. The `-proxy` option can be used multipl= e times to define different proxies for different networks, such as `-proxy=3D127.0.0.1:4444=3Dipv4 -proxy=3D10.0.0.1:6666=3Dipv6`. Later set= tings override earlier ones for the same network; this can be used to remove an earlier all-networks proxy and use direct connections only for a given network, for example `-proxy=3D127.0.0.1:5555 -proxy=3D0=3Dcjdns`. (#3242= 5) - The `-blockmaxweight` startup option has been updated to be debug-only. It is still available to users, but now hidden from the default `-help`= =20 text and shown only in `-help-debug` (#32654). Changes to GUI or wallet related settings can be found in the GUI or Wallet= =20 section below. Wallet ------ - BDB legacy wallets can no longer be created or loaded. They can be=20 migrated to the new descriptor wallet format. Refer to the `migratewallet` RPC for= =20 more details. - The legacy wallet removal drops redundant options in the bitcoin-wallet= =20 tool, such as `-withinternalbdb`, `-legacy`, and `-descriptors`. Moreover, the legacy-only RPCs `addmultisigaddress`, `dumpprivkey`, `dumpwallet`, `importaddress`, `importmulti`, `importprivkey`, `importpubkey`, `importwallet`, `newkeypool`, `sethdseed`, and `upgradewallet`, are=20 removed. (#32944, #28710, #32438, #31250) - Support has been added for spending TRUC transactions received by the wallet, as well as creating TRUC transactions. The wallet ensures that TRUC policy rules are being met. The wallet will throw an error if the user is trying to spend TRUC utxos with utxos of other versions. Additionally, the wallet will treat unconfirmed TRUC sibling transactions as mempool conflicts. The wallet will also ensure that transactions spending TRUC utxos meet the required size restrictions.=20 (#32896) - Since descriptor wallets do not allow mixing watchonly and non-watchonly= =20 descriptors, the `include_watchonly` option (and its variants in naming) are removed= =20 from all RPCs that had it. (#32618) - The `iswatchonly` field is removed from any RPCs that returned it.=20 (#32618) - `unloadwallet` - Return RPC_INVALID_PARAMETER when both the RPC wallet=20 endpoint and wallet_name parameters are unspecified. Previously the RPC failed=20 with a JSON parsing error. (#32845) - `getdescriptoractivity` - Mark blockhashes and scanobjects arguments as= =20 required, so the user receives a clear help message when either is missing. As in= =20 `unloadwallet`, previously the RPC failed with a JSON parsing error. (#32845) - `getwalletinfo` - Removes the fields `balance`, `immature_balance` and `unconfirmed_balance`. (#32721) - `getunconfirmedbalance` - Removes this RPC command. You can query the=20 `getbalances` RPC and inspect the `"mine"` `"untrusted_pending"` entry within the JSON response. (#32721) - The following RPCs now contain a `version` parameter that allows the user to create transactions of any standard version number (1-3): - `createrawtransaction` - `createpsbt` - `send` - `sendall` - `walletcreatefundedpsbt` (#32896) GUI changes ----------- - The GUI has been migrated from Qt 5 to Qt 6. On Windows, dark mode is now= =20 supported. On macOS, the Metal backend is now used. (#30997) - A transaction's fee bump is allowed under fullrbf and no longer requires BIP-125 signalling. (#31953) - Custom column widths in the Transactions tab are reset as a side-effect= =20 of legacy wallet removal. (#32459) Low-level changes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Logs now include which peer sent us a header. Additionally there are fewe= r redundant header log messages. A side-effect of this change is that for some untypical cases new headers aren't logged anymore, e.g. a direct `BLOCK` message with a previously unknown header and `submitheader` RPC.= =20 (#27826) Credits =3D=3D=3D=3D=3D=3D=3D Thanks to everyone who directly contributed to this release: - 0xb10c - amisha - Andrew Toth - Anthony Towns - Antoine Poinsot - Ava Chow - benthecarman - Brandon Odiwuor - brunoerg - Bue-von-hon - Bufo - Chandra Pratap - Chris Stewart - Cory Fields - Daniel Pfeifer - Daniela Brozzoni - David Gumberg - deadmanoz - dennsikl - dergoegge - enoch - Ethan Heilman - Eugene Siegel - Eunovo - Eval EXEC - Fabian Jahr - fanquake - Florian Schmaus - fuder.eth - furszy - glozow - Greg Sanders - Hao Xu - Haoran Peng - Haowen Liu - Hennadii Stepanov - Hodlinator - hoffman - ishaanam - ismaelsadeeq - Jameson Lopp - janb84 - Jiri Jakes - John Bampton - Jon Atack - josibake - jurraca - kevkevin - kevkevinpal - kilavvy - Kristaps Kaupe - l0rinc - laanwj - leopardracer - L=C5=91rinc - Luis Schwab - Luke Dashjr - MarcoFalke - marcofleon - Martin Zumsande - Matt Corallo - Matthew Zipkin - Max Edwards - monlovesmango - Murch - naiyoma - nervana21 - Nicola Leonardo Susca - Novo - pablomartin4btc - Peter Todd - Pieter Wuille - Pol Espinasa - Prabhat Verma - rkrux - Roman Zeyde - Ryan Ofsky - Saikiran - Salvatore Ingala - Sebastian Falbesoner - Sergi Delgado Segura - Shunsuke Shimizu - Sjors Provoost - stickies-v - stratospher - stringintech - strmfos - stutxo - tdb3 - TheCharlatan - Tom=C3=A1s Andr=C3=B3il - UdjinM6 - Vasil Dimov - VolodymyrBg - w0xlt - will - willcl-ark - William Casarin - woltx - yancy - zaidmstrr 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/= 715cfe5a-af73-48f5-a0d9-8b2f22ca6570n%40googlegroups.com. ------=_Part_307397_1977598899.1760260803311 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Bitcoin Core version 30.0 is now available from:

<https://bi= tcoincore.org/bin/bitcoin-core-30.0/>

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

Please report bugs using the issue tr= acker at GitHub:

<https://github.com/bitcoin/bitcoin/issues&= gt;

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

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

With the release of this new major version, versions `27.x`= and
older are at "Maintenance End" and will no longer receive updates= .

In accordance with the security policy, we will in two weeks d= isclose:

* Medium and high severity vulnerabilities fixed in `28= .0`. There are none of these.

* Low severity vulnerabilities fix= ed in `30.0`. There are 5 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
installer (on Wi= ndows) or just copy over `/Applications/Bitcoin-Qt` (on macOS)
or `bit= coind`/`bitcoin-qt` (on Linux).

Upgrading directly from a versio= n of Bitcoin Core that has reached its EOL is
possible, but it might t= ake some time if the data directory needs to be migrated. Old
wallet v= ersions of Bitcoin Core are generally supported.

Compatibility=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Bitcoin Core is s= upported and tested on operating systems using the
Linux Kernel 3.17+,= macOS 13+, and Windows 10+. Bitcoin
Core should also work on most oth= er Unix-like systems but is not as
frequently tested on them. It is no= t recommended to use Bitcoin Core on
unsupported systems.

N= otable changes
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Policy
------

- The maximum number of potentially execute= d legacy signature operations in a
=C2=A0 single standard transaction = is now limited to 2500. Signature operations in all
=C2=A0 previous ou= tput scripts, in all input scripts, as well as all P2SH redeem
=C2=A0 = scripts (if there are any) are counted toward the limit. The new limit is=C2=A0 assumed to not affect any known typically formed standard transa= ctions. The
=C2=A0 change was done to prepare for a possible BIP54 dep= loyment in the future. (#32521)

- `-datacarriersize` is increase= d to 100,000 by default, which effectively uncaps
=C2=A0 the limit (as= the maximum transaction size limit will be hit first). It can be
=C2= =A0 overridden with `-datacarriersize=3D83` to revert to the limit enforced= in previous
=C2=A0 versions. (#32406)

- Multiple data carr= ier (OP_RETURN) outputs in a transaction are now permitted for
=C2=A0 = relay and mining. The `-datacarriersize` limit applies to the aggregate siz= e of
=C2=A0 the scriptPubKeys across all such outputs in a transaction= , not including the
=C2=A0 scriptPubKey size itself. (#32406)
- The minimum block feerate (`-blockmintxfee`) has been changed to 0.001= satoshi per
=C2=A0 vB. It can still be changed using the configuratio= n option. This option can be used
=C2=A0 by miners to set a minimum fe= erate on packages added to block templates. (#33106)

- The defau= lt minimum relay feerate (`-minrelaytxfee`) and incremental relay feerate=C2=A0 (`-incrementalrelayfee`) have been changed to 0.1 satoshis per v= B. They can still
=C2=A0 be changed using their respective configurati= on options, but it is recommended to
=C2=A0 change both together if yo= u decide to do so. (#33106)

=C2=A0 Other minimum feerates (e.g. = the dust feerate, the minimum returned by the fee
=C2=A0 estimator, an= d all feerates used by the wallet) remain unchanged. The mempool minimum=C2=A0 feerate still changes in response to high volume.

=C2= =A0 Note that unless these lower defaults are widely adopted across the net= work, transactions
=C2=A0 created with lower fee rates are not guarant= eed to propagate or confirm. The wallet
=C2=A0 feerates remain unchang= ed; `-mintxfee` must be changed before attempting to create
=C2=A0 tra= nsactions with lower feerates using the wallet. (#33106)

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

- Opportunistic 1-= parent-1-child package relay has been improved to handle
=C2=A0 situat= ions when the child already has unconfirmed parent(s) in the mempool.
= =C2=A0 This means that 1p1c packages can be accepted and propagate, even if= they are
=C2=A0 connected to broader topologies: multi-parent-1-child= (where only 1 parent
=C2=A0 requires fee-bumping), grandparent-parent= -child (where only parent requires
=C2=A0 fee-bumping) etc. (#31385)
- The transaction orphanage, which holds transactions with missin= g inputs temporarily
=C2=A0 while the node attempts to fetch its paren= ts, now has improved Denial of Service protections.
=C2=A0 Previously,= it enforced a maximum number of unique transactions (default 100,
=C2= =A0 configurable using `-maxorphantx`). Now, its limits are as follows: the= number of
=C2=A0 entries (unique by wtxid and peer), plus each unique= transaction's input count divided
=C2=A0 by 10, must not exceed 3,000= . The total weight of unique transactions must not exceed
=C2=A0 `404,= 000` Wu multiplied by the number of peers. (#31829)

- The `-maxo= rphantx` option no longer has any effect, since the orphanage no longer
=C2=A0 limits the number of unique transactions. Users should remove this= configuration
=C2=A0 option if they were using it, as the setting wil= l cause an error in future versions
=C2=A0 when it is no longer recogn= ized. (#31829)

New `bitcoin` command
---------------------<= br />
- A new `bitcoin` command line tool has been added to make featu= res more discoverable
=C2=A0 and convenient to use. The `bitcoin` tool= just calls other executables and does not
=C2=A0 implement any functi= onality on its own. Specifically `bitcoin node` is a synonym for
=C2= =A0 `bitcoind`, `bitcoin gui` is a synonym for `bitcoin-qt`, and `bitcoin r= pc` is a synonym
=C2=A0 for `bitcoin-cli -named`. Other commands and o= ptions can be listed with `bitcoin help`.
=C2=A0 The new `bitcoin` com= mand is an alternative to calling other commands directly, but it
=C2= =A0 doesn't replace them, and there are no plans to deprecate existing comm= ands. (#31375)

External Signing
----------------

- Support for external signing on Windows has been re-enabled. (#29868)
IPC Mining Interface
--------------------

- The ne= w `bitcoin` command does support one new feature: an (experimental) IPC Min= ing
=C2=A0 Interface that allows the node to work with Stratum v2 or o= ther mining client software,
=C2=A0 see (#31098). When the node is sta= rted with `bitcoin -m node -ipcbind=3Dunix` it will
=C2=A0 listen on a= unix socket for IPC client connections, allowing clients to request block<= br />=C2=A0 templates and submit mined blocks. The `-m` option launches a n= ew internal binary
=C2=A0 (`bitcoin-node` instead of `bitcoind`) and i= s currently required but will become optional
=C2=A0 in the future (wi= th #33229).

- IPC connectivity introduces new dependencies (see = [multiprocess.md](https://github.com/bitcoin/bitcoin/blob/master/doc/multip= rocess.md)),
=C2=A0 which can be turned off with the `-DENABLE_IPC=3DO= FF` build option if you do not intend
=C2=A0 to use IPC. (#31802)

Install changes
---------------

- The `test_bitcoin`= executable is now installed in `libexec/` instead of `bin/`.
=C2=A0 I= t can still be executed directly, or accessed through the new `bitcoin` com= mand
=C2=A0 as `bitcoin test`. The `libexec/` directory also contains = new `bitcoin-node` and
=C2=A0 `bitcoin-gui` binaries which support IPC= features and are called through the
=C2=A0 `bitcoin` tool. In source = builds only, `test_bitcoin-qt`, `bench_bitcoin`, and
=C2=A0 `bitcoin-c= hainstate` are also now installed to `libexec/` instead of `bin/` and
= =C2=A0 can be accessed through the new `bitcoin` command. See `bitcoin help= ` output for
=C2=A0 details. (#31679)

- On Windows, the ins= taller no longer adds a =E2=80=9C(64-bit)=E2=80=9D suffix to entries in the=
=C2=A0 Start Menu (#32132), and it now automatically removes obsolete= artifacts during
=C2=A0 upgrades (#33422).

Indexes
--= -----

- The implementation of coinstatsindex was changed to prev= ent an overflow bug that
=C2=A0 could already be observed on the defau= lt Signet. The new version of the index will
=C2=A0 need to be synced = from scratch when starting the upgraded node for the first time.

=C2=A0 The new version is stored in `/indexes/coinstatsindex/` in contrast= to the old version
=C2=A0 which was stored at `/indexes/coinstats/`. = The old version of the index is not deleted
=C2=A0 by the upgraded nod= e in case the user chooses to downgrade their node in the future.
=C2= =A0 If the user does not plan to downgrade it is safe for them to remove `/= indexes/coinstats/`
=C2=A0 from their datadir. A future release of Bit= coin Core may remove the old version of the
=C2=A0 index automatically= . (#30469)

Logging
-------
- Unconditional logging to = disk is now rate limited by giving each source location
=C2=A0 a quota= of 1MiB per hour. Unconditional logging is any logging with a log level=C2=A0 higher than debug, that is `info`, `warning`, and `error`. All lo= gs will be
=C2=A0 prefixed with `[*]` if there is at least one source = location that is currently
=C2=A0 being suppressed. (#32604)

- When `-logsourcelocations` is enabled, the log output now contains the = entire
=C2=A0 function signature instead of just the function name. (#= 32604)

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

- The `-paytxfe= e` startup option and the `settxfee` RPC are now deprecated and
=C2=A0= will be removed in Bitcoin Core 31.0. They allowed the user to set a stati= c fee
=C2=A0 rate for wallet transactions, which could potentially lea= d to overpaying or underpaying.
=C2=A0 Users should instead rely on fe= e estimation or specify a fee rate per transaction
=C2=A0 using the `f= ee_rate` argument in RPCs such as `fundrawtransaction`, `sendtoaddress`,=C2=A0 `send`, `sendall`, and `sendmany`. (#31278)

- Any RPC = in which one of the parameters is a descriptor will throw an error
=C2= =A0 if the provided descriptor contains a whitespace at the beginning or th= e end
=C2=A0 of the public key within a fragment - e.g. `pk( KEY)` or = `pk(KEY )`. (#31603)

- The `submitpackage` RPC, which allows sub= missions of child-with-parents
=C2=A0 packages, no longer requires tha= t all unconfirmed parents be present. The
=C2=A0 package may contain o= ther in-mempool ancestors as well. (#31385)

- The `waitfornewblo= ck` RPC now takes an optional `current_tip` argument. It
=C2=A0 is als= o no longer hidden. (#30635)

- The `waitforblock` and `waitforbl= ockheight` RPCs are no longer hidden. =C2=A0(#30635)

- The `psbt= bumpfee` and `bumpfee` RPCs allow a replacement under fullrbf and no
= =C2=A0 longer require BIP-125 signalling. (#31953)

- Transaction= Script validation errors used to return the reason for the error
=C2= =A0 prefixed by either `mandatory-script-verify-flag-failed` if it was a co= nsensus
=C2=A0 error, or `non-mandatory-script-verify-flag` (without "= -failed") if it was a
=C2=A0 standardness error. This has been changed= to `block-script-verify-flag-failed`
=C2=A0 and `mempool-script-verif= y-flag-failed` for all block and mempool errors
=C2=A0 respectively. (= #33183)

- The `getmininginfo` RPC now returns "blockmintxfee" re= sult specifying the value of
=C2=A0 `-blockmintxfee` configuration. (#= 33189)

- The `getmempoolinfo` RPC now returns an additional "per= mitbaremultisig" and
=C2=A0 "maxdatacarriersize" field, reflecting the= `-permitbaremultisig` and `-datacarriersize`
=C2=A0 config values. (#= 29954)

Changes to wallet-related RPCs can be found in the Wallet= section below.

New RPCs
--------

- A new REST A= PI endpoint (`/rest/spenttxouts/BLOCKHASH`) has been introduced for
= =C2=A0 efficiently fetching spent transaction outputs using the block's und= o data (#32540).

Build System
------------

Updat= ed settings
----------------

- The `-maxmempool` and `-dbca= che` startup parameters are now capped on 32-bit systems
=C2=A0 to 500= MB and 1GiB respectively. (#32530)

- The `-natpmp` option is now= set to `1` by default. This means nodes with `-listen`
=C2=A0 enabled= (the default) but running behind a firewall, such as a local network route= r,
=C2=A0 will be reachable if the firewall/router supports any of the= `PCP` or `NAT-PMP`
=C2=A0 protocols. (#33004)

- The `-upnp= ` setting has now been fully removed. Use `-natpmp` instead. (#32500)
=
- Previously, `-proxy` specified the proxy for all networks (except I= 2P which
=C2=A0 uses `-i2psam`) and only the Tor proxy could have been= specified separately
=C2=A0 via `-onion`. Now, the syntax of `-proxy`= has been extended and it is possible
=C2=A0 to specify separately the= proxy for IPv4, IPv6, Tor and CJDNS by appending `=3D`
=C2=A0 followe= d by the network name, for example `-proxy=3D127.0.0.1:5555=3Dipv6`
= =C2=A0 configures a proxy only for IPv6. The `-proxy` option can be used mu= ltiple
=C2=A0 times to define different proxies for different networks= , such as
=C2=A0 `-proxy=3D127.0.0.1:4444=3Dipv4 -proxy=3D10.0.0.1:666= 6=3Dipv6`. Later settings
=C2=A0 override earlier ones for the same ne= twork; this can be used to remove an
=C2=A0 earlier all-networks proxy= and use direct connections only for a given
=C2=A0 network, for examp= le `-proxy=3D127.0.0.1:5555 -proxy=3D0=3Dcjdns`. (#32425)

- The = `-blockmaxweight` startup option has been updated to be debug-only.
= =C2=A0 It is still available to users, but now hidden from the default `-he= lp` text
=C2=A0 and shown only in `-help-debug` (#32654).

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

Wallet
------

- BDB legacy wallet= s can no longer be created or loaded. They can be migrated
=C2=A0 to t= he new descriptor wallet format. Refer to the `migratewallet` RPC for more<= br />=C2=A0 details.

- The legacy wallet removal drops redundant= options in the bitcoin-wallet tool,
=C2=A0 such as `-withinternalbdb`= , `-legacy`, and `-descriptors`. Moreover, the
=C2=A0 legacy-only RPCs= `addmultisigaddress`, `dumpprivkey`, `dumpwallet`,
=C2=A0 `importaddr= ess`, `importmulti`, `importprivkey`, `importpubkey`,
=C2=A0 `importwa= llet`, `newkeypool`, `sethdseed`, and `upgradewallet`, are removed.
= =C2=A0 (#32944, #28710, #32438, #31250)

- Support has been added= for spending TRUC transactions received by the
=C2=A0 wallet, as well= as creating TRUC transactions. The wallet ensures that
=C2=A0 TRUC po= licy rules are being met. The wallet will throw an error if the
=C2=A0= user is trying to spend TRUC utxos with utxos of other versions.
=C2= =A0 Additionally, the wallet will treat unconfirmed TRUC sibling
=C2= =A0 transactions as mempool conflicts. The wallet will also ensure that
=C2=A0 transactions spending TRUC utxos meet the required size restrictio= ns. (#32896)

- Since descriptor wallets do not allow mixing watc= honly and non-watchonly descriptors,
=C2=A0 the `include_watchonly` op= tion (and its variants in naming) are removed from all RPCs
=C2=A0 tha= t had it. (#32618)

- The `iswatchonly` field is removed from any= RPCs that returned it. (#32618)

- `unloadwallet` - Return RPC_I= NVALID_PARAMETER when both the RPC wallet endpoint
=C2=A0 and wallet_n= ame parameters are unspecified. Previously the RPC failed with a JSON
= =C2=A0 parsing error. (#32845)

- `getdescriptoractivity` - Mark = blockhashes and scanobjects arguments as required,
=C2=A0 so the user = receives a clear help message when either is missing. As in `unloadwallet`,=
=C2=A0 previously the RPC failed with a JSON parsing error. (#32845)<= br />
- `getwalletinfo` - Removes the fields `balance`, `immature_bala= nce` and
=C2=A0 `unconfirmed_balance`. (#32721)

- `getuncon= firmedbalance` - Removes this RPC command. You can query the `getbalances`<= br />=C2=A0 RPC and inspect the `"mine"` `"untrusted_pending"` entry within= the JSON
=C2=A0 response. (#32721)

- The following RPCs no= w contain a `version` parameter that allows
=C2=A0 the user to create = transactions of any standard version number (1-3):
=C2=A0 - `createraw= transaction`
=C2=A0 - `createpsbt`
=C2=A0 - `send`
=C2=A0 - = `sendall`
=C2=A0 - `walletcreatefundedpsbt`
=C2=A0 (#32896)
=
GUI changes
-----------

- The GUI has been migrated f= rom Qt 5 to Qt 6. On Windows, dark mode is now supported.
=C2=A0 On ma= cOS, the Metal backend is now used. (#30997)

- A transaction's f= ee bump is allowed under fullrbf and no longer requires
=C2=A0 BIP-125= signalling. (#31953)

- Custom column widths in the Transactions= tab are reset as a side-effect of legacy
=C2=A0 wallet removal. (#324= 59)

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

- Logs now include which peer sent us a header. = Additionally there are fewer
=C2=A0 redundant header log messages. A s= ide-effect of this change is that for
=C2=A0 some untypical cases new = headers aren't logged anymore, e.g. a direct
=C2=A0 `BLOCK` message wi= th a previously unknown header and `submitheader` RPC. (#27826)

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

Thanks to everyone who direct= ly contributed to this release:

- 0xb10c
- amisha
- An= drew Toth
- Anthony Towns
- Antoine Poinsot
- Ava Chow
= - benthecarman
- Brandon Odiwuor
- brunoerg
- Bue-von-hon- Bufo
- Chandra Pratap
- Chris Stewart
- Cory Fields
- Daniel Pfeifer
- Daniela Brozzoni
- David Gumberg
- dead= manoz
- dennsikl
- dergoegge
- enoch
- Ethan Heilman- Eugene Siegel
- Eunovo
- Eval EXEC
- Fabian Jahr
-= fanquake
- Florian Schmaus
- fuder.eth
- furszy
- gloz= ow
- Greg Sanders
- Hao Xu
- Haoran Peng
- Haowen Liu- Hennadii Stepanov
- Hodlinator
- hoffman
- ishaanam- ismaelsadeeq
- Jameson Lopp
- janb84
- Jiri Jakes
= - John Bampton
- Jon Atack
- josibake
- jurraca
- kevke= vin
- kevkevinpal
- kilavvy
- Kristaps Kaupe
- l0rinc- laanwj
- leopardracer
- L=C5=91rinc
- Luis Schwab
- Luke Dashjr
- MarcoFalke
- marcofleon
- Martin Zumsande- Matt Corallo
- Matthew Zipkin
- Max Edwards
- monloves= mango
- Murch
- naiyoma
- nervana21
- Nicola Leonardo S= usca
- Novo
- pablomartin4btc
- Peter Todd
- Pieter Wui= lle
- Pol Espinasa
- Prabhat Verma
- rkrux
- Roman Zeyd= e
- Ryan Ofsky
- Saikiran
- Salvatore Ingala
- Sebastia= n Falbesoner
- Sergi Delgado Segura
- Shunsuke Shimizu
- Sjo= rs Provoost
- stickies-v
- stratospher
- stringintech
-= strmfos
- stutxo
- tdb3
- TheCharlatan
- Tom= =C3=A1s Andr=C3=B3il
- UdjinM6
- Vasil Dimov
- VolodymyrBg- w0xlt
- will
- willcl-ark
- William Casarin
- wol= tx
- yancy
- zaidmstrr

As well as to everyone that hel= ped with translations on
[Transifex](https://explore.transifex.com/bit= coin/bitcoin/).

--
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/715cfe5a-af73-48f5-a0d9-8b2f22ca6570n%40googlegroups.com.
------=_Part_307397_1977598899.1760260803311-- ------=_Part_307396_451024727.1760260803311--