Inside Bitcoin
Opening the selected file…
Opening the selected file…
The code behind the network, with room to understand it.
Release published 2026-10-28 · Snapshot fetched 2026-11-01. Latest stable release at fetch time; development branches and Git history are excluded. Only the selected code window and visible folders load here.
1v31.0 Release Notes2===================4Bitcoin Core version 31.0 is now available from:6<https://bitcoincore.org/bin/bitcoin-core-31.0/>8This release includes new features, various bug fixes and performance9improvements, as well as updated translations.11Please report bugs using the issue tracker at GitHub:13<https://github.com/bitcoin/bitcoin/issues>15To receive security and update notifications, please subscribe to:17<https://bitcoincore.org/en/list/announcements/join/>20With the release of this new major version, versions `28.x` and21older are at "End of Life" and will no longer receive updates.23In accordance with the security policy, we will in two weeks disclose:25* Medium and high severity vulnerabilities fixed in `29.0`. There is one of these.27* Low severity vulnerabilities fixed in `31.0`. There are none of these.29How to Upgrade30==============32If you are running an older version, shut it down. Wait until it has completely33shut down (which might take a few minutes in some cases), then run the installer34(on Windows) or just copy over `/Applications/Bitcoin-Qt` (on macOS) or35`bitcoind`/`bitcoin-qt` (on Linux).37Upgrading directly from a version of Bitcoin Core that has reached its EOL is38possible, but it might take some time if the data directory needs to be39migrated. Old wallet versions of Bitcoin Core are generally supported.41Compatibility42==============44Bitcoin Core is supported and tested on the following operating systems or45newer: Linux Kernel 3.17, macOS 14, and Windows 10 (version 1903). Bitcoin Core46should also work on most other Unix-like systems but is not as frequently tested47on them. It is not recommended to use Bitcoin Core on unsupported systems.49Notable changes50===============52The default `-dbcache` value has been increased to 1024 MiB from 450 MiB on53systems where at least 4096 MiB of RAM is detected. This improves performance54but increases memory usage. On some systems (for example when running in55containers), the detected RAM may exceed the memory actually available, which56can lead to out-of-memory conditions. To maintain the previous behavior, set57`-dbcache=450`. See58[reduce-memory.md](https://github.com/bitcoin/bitcoin/blob/master/doc/reduce-memory.md)59for further guidance on low-memory systems. (#34692)61Mempool62-------64The mempool has been reimplemented with a new design ("cluster mempool"), to65facilitate better decision-making when constructing block templates, evicting66transactions, relaying transactions, and validating replacement transactions67(RBF). Most changes should be transparent to users, but some behavior changes68are noted:70- The mempool no longer enforces ancestor or descendant size/count limits.71Instead, two new default policy limits are introduced governing connected72components, or clusters, in the mempool, limiting clusters to 64 transactions73and up to 101 kB in virtual size. Transactions are considered to be in the same74cluster if they are connected to each other via any combination of parent/child75relationships in the mempool. These limits can be overridden using command-line76arguments; see the extended help (`-help-debug`) for more information.78- Within the mempool, transactions are ordered based on the feerate at which79they are expected to be mined, which takes into account the full set, or80"chunk", of transactions that would be included together (e.g., a parent and its81child, or more complicated subsets of transactions). This ordering is utilized82by the algorithms that implement transaction selection for constructing block83templates; eviction from the mempool when it is full; and transaction relay84announcements to peers.86- The replace-by-fee validation logic has been updated so that transaction87replacements are only accepted if the resulting mempool's feerate diagram is88strictly better than before the replacement. This eliminates all known cases of89replacements occurring that make the mempool worse off, which was possible under90previous RBF rules. For singleton transactions (that are in clusters by91themselves) it's sufficient for a replacement to have a higher fee and feerate92than the original. See [delvingbitcoin.org93post](https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393#rbf-can-now-be-made-incentive-compatible-for-miners-11)94for more information.96- Two new RPCs have been added: `getmempoolcluster` will provide the set of97transactions in the same cluster as the given transaction, along with the98ordering of those transactions and grouping into chunks; and99`getmempoolfeeratediagram` will return the feerate diagram of the entire100mempool.102- Chunk size and chunk fees are now also included in the output of103`getmempoolentry`.105- The "CPFP Carveout" has been removed from the mempool logic. The CPFP carveout106allowed one additional child transaction to be added to a package that's already107at its descendant limit, but only if that child has exactly one ancestor (the108package's root) and is small (no larger than 10kvB). Nothing is allowed to109bypass the cluster count limit. It is expected that smart contracting use-cases110requiring similar functionality employ TRUC transactions and sibling eviction111instead going forward.113- Some additional discussion can be found at114[doc/policy/mempool-terminology.md](https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-terminology.md)115and116[doc/policy/mempool-replacements.md](https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md).118P2P and network changes119-----------------------121- Normally local transactions are broadcast to all connected peers with which we122do transaction relay. Now, for the `sendrawtransaction` RPC this behavior can be123changed to only do the broadcast via the Tor or I2P networks. A new boolean124option `-privatebroadcast` has been added to enable this behavior. This improves125the privacy of the transaction originator in two aspects:1261. Their IP address (and thus geolocation) is never known to the recipients.1272. If the originator sends two otherwise unrelated transactions, they will not128be linkable. This is because a separate connection is used for broadcasting129each transaction. (#29415)131- New RPCs have been added to introspect and control private broadcast:132`getprivatebroadcastinfo` reports transactions currently being privately133broadcast, and `abortprivatebroadcast` removes matching transactions from the134private broadcast queue. (#34329)136- Transactions participating in one-parent-one-child package relay can now have137the parent with a feerate lower than the `-minrelaytxfee` feerate, even 0 fee.138This expands the change from 28.0 to also cover packages of non-TRUC139transactions. Note that in general the package child can have additional140unconfirmed parents, but they must already be in-mempool for the new package to141be relayed. (#33892)143- The release has asmap data embedded for the first time, allowing the asmap144feature to be used without any externally sourced file. The embedded map [was145created on 2026-03-05](https://github.com/bitcoin/bitcoin/pull/34696). Despite146the data being available, the option remains off-by-default. Users still need to147set `-asmap` or `-asmap=1` explicitly to make it possible to use a peer's ASN148(ISP/hoster identifier) in netgroup bucketing in order to ensure a higher149diversity in their peer set.151Updated RPCs152------------154- `gettxspendingprevout` has 2 new optional arguments: `mempool_only` and155`return_spending_tx`. If `mempool_only` is true it will limit scans to the156mempool even if `txospenderindex` is available. If `return_spending_tx` is true,157the full spending tx will be returned. In addition if `txospenderindex` is158available and a confirmed spending transaction is found, its block hash will be159returned. (#24539)161- The `getpeerinfo` RPC no longer returns the `startingheight` field unless the162configuration option `-deprecatedrpc=startingheight` is used. The163`startingheight` field will be fully removed in the next major release. (#34197)165- The `getblock` RPC now returns a `coinbase_tx` object at verbosity levels 1,1662, and 3. It contains `version`, `locktime`, `sequence`, `coinbase` and167`witness`. This allows for efficiently querying coinbase transaction properties168without fetching the full transaction data at verbosity 2+. (#34512)170REST API171--------173- A new REST API endpoint174(`/rest/blockpart/<BLOCK-HASH>.<bin|hex>?offset=<OFFSET>&size=<SIZE>`) has been175introduced for efficiently fetching a range of bytes from block `<BLOCK-HASH>`.176(#33657)178Build System179------------181- The minimum supported Clang compiler version has been raised to 17.0 (#33555).182- The minimum supported GCC compiler version has been raised to 12.1 (#33842).184Updated settings185----------------187- The `-paytxfee` startup option and the `settxfee` RPC are now deleted after188being deprecated in Bitcoin Core 30.0. They used to allow the user to set a189static fee rate for wallet transactions, which could potentially lead to190overpaying or underpaying. Users should instead rely on fee estimation or191specify a fee rate per transaction using the `fee_rate` argument in RPCs such as192`fundrawtransaction`, `sendtoaddress`, `send`, `sendall`, and `sendmany`.193(#32138)195- Specifying `-asmap` or `-asmap=1` will load the embedded asmap data instead of196an external file. In previous releases, if `-asmap` was specified without a197filename, this would try to load an `ip_asn.map` data file. Now loading an198external asmap file always requires an explicit filename like199`-asmap=ip_asn.map`.201- The `-maxorphantx` startup option has been removed. It was previously202deprecated and has no effect anymore since v30.0. (#33872)204- `tor` has been removed as a network specification. It was deprecated in favour205of `onion` in v0.17.0. (#34031)207- When `-logsourcelocations` is enabled, the log output now contains just the208function name instead of the entire function signature. (#34088)210- The default `-dbcache` value has been increased to `1024` MiB from `450` MiB211on systems where at least `4096` MiB of RAM is detected. This is a performance212increase, but will use more memory. To maintain the previous behaviour, set213`-dbcache=450`. (#34692)215- `-privatebroadcast` is added to enable private broadcast behavior for216`sendrawtransaction`.218New settings219------------221- `-txospenderindex` enables the creation of a transaction output spender index222that, if present, will be scanned by `gettxspendingprevout` if a spending223transaction was not found in the mempool. (#24539)225GUI changes226-----------228- The GUI has been updated to Qt 6.8. (#34650)230- The `createwallet`, `createwalletdescriptor` and `migratewallet` commands are231filtered from the console history to improve security and privacy. (gui#901)233- The Restore Wallet dialog shows an error message if the restored wallet name234is empty. (gui#924)236Fee Estimation237--------------239The Bitcoin Core fee estimator minimum fee rate bucket was updated from **1240sat/vB** to **0.1 sat/vB**, which matches the node’s default `minrelaytxfee`. This241means that for a given confirmation target, if a sub-1 sat/vB fee rate bucket is242the minimum tracked with sufficient data, its average value will be returned as243the fee rate estimate.245Restarting a node with this change invalidates previously saved246estimates in `fee_estimates.dat`, the fee estimator will start tracking fresh247stats.249IPC Interface250-------------
Independent explanations by MyBitcoinExplorer. Not affiliated with or endorsed by Bitcoin Core. Guides are educational and do not replace the source or its tests.
Bitcoin Core source © its contributors, distributed under the MIT license. Original notices and bundled third-party licenses are retained in the source tree.