29.0 Release Notes draft

Release Notes Draft for v29.0

FIXME Normal sections: How to Upgrade Compatibility

Notable Changes

P2P and Network Changes

• Support for UPnP was dropped. If you want to open a port automatically, consider using the -natpmp option instead, which uses PCP or NAT-PMP depending on router support. (#31130)

• When the -port configuration option is used, the default onion listening port will now 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

• Ephemeral dust is a new concept that allows a single 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)

• (FIXME reword/trim) PR #31384 fixed an issue where block reserved weight for fixed-size block header, transactions count, and coinbase transaction was done in two separate places. Before this pull request, the policy default for the maximum block weight was 3,996,000 WU, calculated by subtracting 4,000 WU from the 4,000,000 WU consensus limit to account for the fixed-size block header, transactions count, and coinbase transaction. During block assembly, Bitcoin Core clamped custom -blockmaxweight value to not be more than the policy default. Additionally, the mining code added another 4,000 WU to the initial reservation, reducing the effective block template size to 3,992,000 WU. Due to this issue, the total reserved weight was always 8,000 WU, meaning that even when specifying a -blockmaxweight higher than the policy default, the actual block size never exceeded 3,992,000 WU. The fix consolidates the reservation into a single place and introduces a new startup option, -blockreservedweight (default: 8,000 WU). This startup option specifies the reserved weight for the fixed-size block header, transactions count, and coinbase transaction. The default value of -blockreservedweight was chosen to preserve the previous behavior. Upgrade Note: The default -blockreservedweight ensures backward compatibility for users who relied on the previous behavior. Users who manually set -blockmaxweight to its maximum value of 4,000,000 WU should be aware that this value previously had no effect since it was clamped to 3,996,000 WU. Users lowering -blockreservedweight should ensure that the total weight (for the block header, transaction count, and coinbase transaction) does not exceed the reduced value.

Updated RPCs

• The RPC testmempoolaccept response now includes a "reject-details" field in some cases, similar to the complete error messages returned by sendrawtransaction (#28121)

• Duplicate blocks submitted with submitblock will now persist their block data 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)

• 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)

• getblock and getblockheader now return the current target in the target field (#31583)

• getblockchaininfo and getchainstates now return nBits and the current target in the target field (#31583)

• the getblocktemplate RPC curtime (BIP22) and mintime (BIP23) fields now 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

• getdescriptoractivity can be used to find all spend/receive activity relevant to 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

• GET /rest/block/<BLOCK-HASH>.json and GET /rest/headers/<BLOCK-HASH>.json now return the current target in the target field

Updated Settings

• The maximum allowed value for the -dbcache configuration option has been 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)

• 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.

• Starting with v28.0, the mempoolfullrbf startup option was set to 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)

• Setting -upnp will now cause a warning and have no effect. Consider using -natpmp instead. (#31130)

• 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 weight units.

• 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.

Wallet

GUI Changes

Low-Level Changes

Build System

• (FIXME) CMake

Tools and Utilities

• A new tool utxo_to_sqlite.py 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

• The BIP94 timewarp attack mitigation (designed for testnet4) is no longer active on the regtest network. (#31156)

Dependencies

Credits

(FIXME, waiting until a few more things are merged)