release-notes-29.0.md raw

Bitcoin Core version 29.0 is now available from:

<https://bitcoincore.org/bin/bitcoin-core-29.0/>

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:

<https://github.com/bitcoin/bitcoin/issues>

To receive security and update notifications, please subscribe to:

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

How to Upgrade ==============

If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes in some cases), then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on macOS) or bitcoind/bitcoin-qt (on Linux).

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

Compatibility ==============

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 ===============

P2P and Network Changes

option instead, which uses PCP or NAT-PMP depending on router support. (#31130)

be derived to be that port + 1 instead of being set to a fixed value (8334 on mainnet). This re-allows setups with multiple local nodes using different -port and not using -bind, which would lead to a startup failure in v28.0 due to a port collision. Note that a HiddenServicePort manually configured in torrc may need adjustment if used in connection with the -port option. For example, if you are using -port=5555 with a non-standard value and not using -bind=...=onion, previously Bitcoin Core would listen for incoming Tor connections on 127.0.0.1:8334. Now it would listen on 127.0.0.1:5556 (-port plus one). If you configured the hidden service manually in torrc now you have to change it from HiddenServicePort 8333 127.0.0.1:8334 to `HiddenServicePort 8333 127.0.0.1:5556, or configure bitcoind with -bind=127.0.0.1:8334=onion` to get the previous behavior. (#31223)

Mempool Policy and Mining Changes

dust output in a transaction, provided the transaction is zero fee. In order to spend any unconfirmed outputs from this transaction, the spender must also spend this dust in addition to any other desired outputs. In other words, this type of transaction should be created in a transaction package where the dust is both created and spent simultaneously. (#30239)

The 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. The 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)

Updated RPCs

similar to the complete error messages returned by sendrawtransaction (#28121)

even if it was previously pruned. If pruning is activated, the data will be pruned again eventually once the block file it is persisted in is selected for pruning. This is consistent with the behaviour of getblockfrompeer where the block is persisted as well even when pruning. (#31175)

account for the timewarp fix proposed in BIP94 on all networks. This ensures that, in the event a timewarp fix softfork activates on mainnet, un-upgraded miners will not accidentally violate the timewarp rule. (#31376, #31600) As a reminder, it's important that any software which uses the getblocktemplate RPC takes these values into account (either curtime or mintime is fine). Relying only on a clock can lead to invalid blocks under some circumstances, especially once a timewarp fix is deployed. (#31600)

New RPCs

a given set of descriptors within a set of specified blocks. This call can be used with scanblocks to lessen the need for additional indexing programs. (#30708)

Updated REST APIs

Updated Settings

dropped due to recent UTXO set growth. Note that before this change, large -dbcache values were automatically reduced to 16 GiB (1 GiB on 32 bit systems). (#28358)

default to 1. With widespread adoption of this policy, users no longer benefit from disabling it, so the option has been removed, making full replace-by-fee the standard behavior. (#30592)

Build System

The build system has been migrated from Autotools to CMake:

  1. The minimum required CMake version is 3.22.
  2. 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".
  3. 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 for details.
  4. 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.
  5. By default, the built executables and libraries are located in the bin/ and lib/ subdirectories of the build directory.
  6. The build system supports component‐based installation. The names of the installable components coincide with the build target names. For example:
cmake -B build
cmake --build build --target bitcoind
cmake --install build --component bitcoind
  1. 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.

For more detailed guidance on configuring and using CMake, please refer to the official CMake documentation and CMake’s User Interaction Guide. Additionally, consult platform-specific doc/build-*.md build guides for instructions tailored to your operating system.

Low-Level Changes

Tools and Utilities

converts a compact-serialized UTXO snapshot (as created with the dumptxoutset RPC) to a SQLite3 database. Refer to the script's --help output for more details. (#27432)

Tests

Dependencies

Credits =======

Thanks to everyone who directly contributed to this release:

As well as to everyone that helped with translations on Transifex.