Inside Bitcoin
Opening the selected file…
Inside Bitcoin
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.
1Bitcoin Core version 29.0 is now available from:3<https://bitcoincore.org/bin/bitcoin-core-29.0/>5This release includes new features, various bug fixes and performance6improvements, as well as updated translations.8Please report bugs using the issue tracker at GitHub:10<https://github.com/bitcoin/bitcoin/issues>12To receive security and update notifications, please subscribe to:14<https://bitcoincore.org/en/list/announcements/join/>16How to Upgrade17==============19If you are running an older version, shut it down. Wait until it has completely20shut down (which might take a few minutes in some cases), then run the21installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on macOS)22or `bitcoind`/`bitcoin-qt` (on Linux).24Upgrading directly from a version of Bitcoin Core that has reached its EOL is25possible, but it might take some time if the data directory needs to be migrated. Old26wallet versions of Bitcoin Core are generally supported.28Compatibility29==============31Bitcoin Core is supported and tested on operating systems using the32Linux Kernel 3.17+, macOS 13+, and Windows 10+. Bitcoin33Core should also work on most other Unix-like systems but is not as34frequently tested on them. It is not recommended to use Bitcoin Core on35unsupported systems.37Notable changes38===============40### P2P and Network Changes42- Support for UPnP was dropped. If you want to open a port automatically, consider using the `-natpmp`43option instead, which uses PCP or NAT-PMP depending on router support. (#31130)45- libnatpmp was replaced with a built-in implementation of PCP and NAT-PMP (still enabled using the `-natpmp` option). This supports automatic IPv4 port forwarding as well as IPv6 pinholing. (#30043)47- When the `-port` configuration option is used, the default onion listening port will now48be derived to be that port + 1 instead of being set to a fixed value (8334 on mainnet).49This re-allows setups with multiple local nodes using different `-port` and not using `-bind`,50which would lead to a startup failure in v28.0 due to a port collision.51Note that a `HiddenServicePort` manually configured in `torrc` may need adjustment if used in52connection with the `-port` option.53For example, if you are using `-port=5555` with a non-standard value and not using `-bind=...=onion`,54previously Bitcoin Core would listen for incoming Tor connections on `127.0.0.1:8334`.55Now it would listen on `127.0.0.1:5556` (`-port` plus one). If you configured the hidden service manually56in torrc now you have to change it from `HiddenServicePort 8333 127.0.0.1:8334` to `HiddenServicePort 833357127.0.0.1:5556`, or configure bitcoind with `-bind=127.0.0.1:8334=onion` to get the previous behavior.58(#31223)60- Upon receiving an orphan transaction (an unconfirmed transaction that spends unknown inputs), the node will attempt to download missing parents from all peers who announced the orphan. This change may increase bandwidth usage but make orphan-handling more reliable. (#31397)62### Mempool Policy and Mining Changes64- Ephemeral dust is a new concept that allows a single65dust output in a transaction, provided the transaction66is zero fee. In order to spend any unconfirmed outputs67from this transaction, the spender must also spend68this dust in addition to any other desired outputs.69In other words, this type of transaction70should be created in a transaction package where71the dust is both created and spent simultaneously. (#30239)73- Due to a bug, the default block reserved weight (`4,000 WU`) for fixed-size block header, transactions count, and coinbase transaction was reserved twice and could not be lowered. As a result the total reserved weight was always `8,000 WU`, meaning that even when specifying a `-blockmaxweight` higher than the default (even to the max of `4,000,000 WU`), the actual block size will never exceed `3,992,000 WU`.74The fix consolidates the reservation into a single place and introduces a new startup option, `-blockreservedweight` which specifies the reserved weight directly. The default value of `-blockreservedweight` is set to `8,000 WU` to ensure backward compatibility for users who relied on the previous behavior of `-blockmaxweight`.75The minimum value of `-blockreservedweight` is set to `2,000 WU`. Users setting `-blockreservedweight` below the default should ensure that the total weight of their block header, transaction count, and coinbase transaction does not exceed the reduced value or they may risk mining an invalid block. (#31384)77### Updated RPCs79- The RPC `testmempoolaccept` response now includes a `reject-details` field in some cases,80similar to the complete error messages returned by `sendrawtransaction` (#28121)82- Duplicate blocks submitted with `submitblock` will now persist their block data83even if it was previously pruned. If pruning is activated, the data will be84pruned again eventually once the block file it is persisted in is selected for85pruning. This is consistent with the behaviour of `getblockfrompeer` where the86block is persisted as well even when pruning. (#31175)88- `getmininginfo` now returns `nBits` and the current target in the `target` field. It also returns a `next` object which specifies the `height`, `nBits`, `difficulty`, and `target` for the next block. (#31583)90- `getblock` and `getblockheader` now return the current target in the `target` field (#31583)92- `getblockchaininfo` and `getchainstates` now return `nBits` and the current target in the `target` field (#31583)94- the `getblocktemplate` RPC `curtime` (BIP22) and `mintime` (BIP23) fields now95account for the timewarp fix proposed in BIP94 on all networks. This ensures96that, in the event a timewarp fix softfork activates on mainnet, un-upgraded97miners will not accidentally violate the timewarp rule. (#31376, #31600)98As a reminder, it's important that any software which uses the `getblocktemplate`99RPC takes these values into account (either `curtime` or `mintime` is fine).100Relying only on a clock can lead to invalid blocks under some circumstances,101especially once a timewarp fix is deployed. (#31600)103### New RPCs105- `getdescriptoractivity` can be used to find all spend/receive activity relevant to106a given set of descriptors within a set of specified blocks. This call can be used with107`scanblocks` to lessen the need for additional indexing programs. (#30708)109### Updated REST APIs111- `GET /rest/block/<BLOCK-HASH>.json` and `GET /rest/headers/<BLOCK-HASH>.json` now return the current target in the `target` field113### Updated Settings115- The maximum allowed value for the `-dbcache` configuration option has been116dropped due to recent UTXO set growth. Note that before this change, large `-dbcache`117values were automatically reduced to 16 GiB (1 GiB on 32 bit systems). (#28358)119- Handling of negated `-noseednode`, `-nobind`, `-nowhitebind`, `-norpcbind`, `-norpcallowip`, `-norpcwhitelist`, `-notest`, `-noasmap`, `-norpcwallet`, `-noonlynet`, and `-noexternalip` options has changed. Previously negating these options had various confusing and undocumented side effects. Now negating them just resets the settings and restores default behaviors, as if the options were not specified.121- Starting with v28.0, the `-mempoolfullrbf` startup option was set to122default to `1`. With widespread adoption of this policy, users no longer123benefit from disabling it, so the option has been removed, making full124replace-by-fee the standard behavior. (#30592)126- Setting `-upnp` will now log a warning and be interpreted as `-natpmp`. Consider using `-natpmp` directly instead. (#31130, #31916)128- As a safety check, Bitcoin core will **fail to start** when `-blockreservedweight` init parameter value is lower than `2000` weight units. Bitcoin Core will also **fail to start** if the `-blockmaxweight` or `-blockreservedweight` init parameter exceeds consensus limit of `4,000,000 WU`.130- Passing `-debug=0` or `-debug=none` now behaves like `-nodebug`: previously set debug categories will be cleared, but subsequent `-debug` options will still be applied.132- The default for `-rpcthreads` has been changed from 4 to 16, and the default for `-rpcworkqueue` has been changed from 16 to 64. (#31215).134### Build System136The build system has been migrated from Autotools to CMake:1381. The minimum required CMake version is 3.22.1392. In-source builds are not allowed. When using a subdirectory within the root source tree as a build directory, it is recommended that its name includes the substring "build".1403. CMake variables may be used to configure the build system. **Some defaults have changed.** For example, you will now need to add `-DWITH_ZMQ=ON` to build with zmq and `-DBUILD_GUI=ON` to build `bitcoin-qt`. See [Autotools to CMake Options Mapping](https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Autotools-to-CMake-Options-Mapping) for details.1414. For single-configuration generators, the default build configuration (`CMAKE_BUILD_TYPE`) is "RelWithDebInfo". However, for the "Release" configuration, CMake defaults to the compiler optimization flag `-O3`, which has not been extensively tested with Bitcoin Core. Therefore, the build system replaces it with `-O2`.1425. By default, the built executables and libraries are located in the `bin/` and `lib/` subdirectories of the build directory.1436. The build system supports component‐based installation. The names of the installable components coincide with the build target names. For example:144```145cmake -B build146cmake --build build --target bitcoind147cmake --install build --component bitcoind148```1507. If any of the `CPPFLAGS`, `CFLAGS`, `CXXFLAGS` or `LDFLAGS` environment variables were used in your Autotools-based build process, you should instead use the corresponding CMake variables (`APPEND_CPPFLAGS`, `APPEND_CFLAGS`, `APPEND_CXXFLAGS` and `APPEND_LDFLAGS`). Alternatively, if you opt to use the dedicated `CMAKE_<...>_FLAGS` variables, you must ensure that the resulting compiler or linker invocations are as expected.152For more detailed guidance on configuring and using CMake, please refer to the official [CMake documentation](https://cmake.org/cmake/help/latest/) and [CMake’s User Interaction Guide](https://cmake.org/cmake/help/latest/guide/user-interaction/index.html). Additionally, consult platform-specific `doc/build-*.md` build guides for instructions tailored to your operating system.154## Low-Level Changes156### Tools and Utilities158- A new tool [`utxo_to_sqlite.py`](https://github.com/bitcoin/bitcoin/blob/v29.0/contrib/utxo-tools/utxo_to_sqlite.py)159converts a compact-serialized UTXO snapshot (as created with the160`dumptxoutset` RPC) to a SQLite3 database. Refer to the script's `--help`161output for more details. (#27432)163### Tests165- The BIP94 timewarp attack mitigation (designed for testnet4) is no longer active on the regtest network. (#31156)167### Dependencies169- MiniUPnPc and libnatpmp have been removed as dependencies (#31130, #30043).171Credits172=======174Thanks to everyone who directly contributed to this release:176- 0xb10c177- Adlai Chandrasekhar178- Afanti179- Alfonso Roman Zubeldia180- am-sq181- Andre182- Andre Alves183- Anthony Towns184- Antoine Poinsot185- Ash Manning186- Ava Chow187- Boris Nagaev188- Brandon Odiwuor189- brunoerg190- Chris Stewart191- Cory Fields192- costcould193- Daniel Pfeifer194- Daniela Brozzoni195- David Gumberg196- dergoegge197- epysqyli198- espi3199- Eval EXEC200- Fabian Jahr201- fanquake202- furszy203- Gabriele Bocchi204- glozow205- Greg Sanders206- Gutflo207- Hennadii Stepanov208- Hodlinator209- i-am-yuvi210- ion-211- ismaelsadeeq212- Jadi213- James O'Beirne214- Jeremy Rand215- Jon Atack216- jurraca217- Kay218- kevkevinpal219- l0rinc220- laanwj221- Larry Ruane222- Lőrinc223- Maciej S. Szmigiero224- Mackain225- MarcoFalke226- marcofleon227- Marnix228- Martin Leitner-Ankerl229- Martin Saposnic230- Martin Zumsande231- Matthew Zipkin232- Max Edwards233- Michael Dietz234- naiyoma235- Nicola Leonardo Susca236- omahs237- pablomartin4btc238- Pieter Wuille239- Randall Naar240- RiceChuan241- rkrux242- Roman Zeyde243- Ryan Ofsky244- Sebastian Falbesoner245- secp512k2246- Sergi Delgado Segura247- Simon248- Sjors Provoost249- stickies-v250- Suhas Daftuar
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.