delete release note fragments for v29

doc/release-notes-27432.md

@@ -1,7 +0,0 @@
-Tools and Utilities
--------------------
-
-- A new tool [`utxo_to_sqlite.py`](/contrib/utxo-tools/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)

doc/release-notes-28121.md

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

doc/release-notes-28358.md

@@ -1,6 +0,0 @@
-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)

doc/release-notes-30239.md

@@ -1,12 +0,0 @@
-P2P and network 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 outputs.
-
-In other words, this type of transaction
-should be created in a transaction package where
-the dust is both created and spent simultaneously.

doc/release-notes-30529.md

@@ -1,4 +0,0 @@
-Configuration
--------------
-
-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.

doc/release-notes-30592.md

@@ -1,7 +0,0 @@
-Full Replace-By-Fee
-===================
-
-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)

doc/release-notes-30708.md

@@ -1,6 +0,0 @@
-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.

doc/release-notes-31130.md

@@ -1,10 +0,0 @@
-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.
-
-Updated settings
-------
-
-- Setting `-upnp` will now return an error. Consider using `-natpmp` instead.

doc/release-notes-31156.md

@@ -1,4 +0,0 @@
-Test
-------
-
-The BIP94 timewarp attack mitigation (designed for testnet4) is no longer active on the regtest network. (#31156)

doc/release-notes-31175.md

@@ -1,8 +0,0 @@
-RPC
----
-
-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.

doc/release-notes-31223.md

@@ -1,15 +0,0 @@
-P2P and network changes
------------------------
-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)

doc/release-notes-31384.md

@@ -1,34 +0,0 @@
-- Node and Mining
-
----
-
-- **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.
-
-  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.

doc/release-notes-31583.md

@@ -1,9 +0,0 @@
-Updated RPCs
----
-- `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.
-- `getblock` and `getblockheader` now return the current target in the `target` field
-- `getblockchaininfo` and `getchainstates` now return `nBits` and the current target in the `target` field
-
-REST interface
----
-- `GET /rest/block/<BLOCK-HASH>.json` and `GET /rest/headers/<BLOCK-HASH>.json` now return the current target in the `target` field

doc/release-notes-31600.md

@@ -1,11 +0,0 @@
-Updated RPCs
----
-- 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.

doc/release-notes-31767.md

@@ -1,3 +0,0 @@
-Logging
----
-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.