doc: clean out release notes post branch-off

1 files changed, 1 insertions, 124 deletions

diff --git a/doc/release-notes.md b/doc/release-notes.md
index 013ed891ee..99f26fc943 100644
--- a/doc/release-notes.md
+++ b/doc/release-notes.md
@@ -1,5 +1,3 @@
-# Release notes now being edited on https://github.com/bitcoin-core/bitcoin-devwiki/wiki/22.0-Release-Notes-draft
-
 *After branching off for a major version release of Bitcoin Core, use this
 template to create the initial release notes draft.*
 
@@ -8,7 +6,7 @@ template to create the initial release notes draft.*
 for the process.*
 
 *Create the draft, named* "*version* Release Notes Draft"
-*(e.g. "0.20.0 Release Notes Draft"), as a collaborative wiki in:*
+*(e.g. "22.0 Release Notes Draft"), as a collaborative wiki in:*
 
 https://github.com/bitcoin-core/bitcoin-devwiki/wiki/
 
@@ -53,90 +51,15 @@ 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.
 
-From Bitcoin Core 22.0 onwards, macOS versions earlier than 10.14 are no longer supported.
-
 Notable changes
 ===============
 
 P2P and network changes
 -----------------------
 
-- This release removes support for Tor version 2 hidden services in favor of Tor
-  v3 only, as the Tor network [dropped support for Tor
-  v2](https://blog.torproject.org/v2-deprecation-timeline) with the release of
-  Tor version 0.4.6.  Henceforth, Bitcoin Core ignores Tor v2 addresses; it
-  neither rumors them over the network to other peers, nor stores them in memory
-  or to `peers.dat`.  (#22050)
-
-- Added NAT-PMP port mapping support via
-  [`libnatpmp`](https://miniupnp.tuxfamily.org/libnatpmp.html). (#18077)
-
 Updated RPCs
 ------------
 
-- Due to [BIP 350](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki)
-  being implemented, behavior for all RPCs that accept addresses is changed when
-  a native witness version 1 (or higher) is passed. These now require a Bech32m
-  encoding instead of a Bech32 one, and Bech32m encoding will be used for such
-  addresses in RPC output as well. No version 1 addresses should be created
-  for mainnet until consensus rules are adopted that give them meaning
-  (e.g. through [BIP 341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki)).
-  Once that happens, Bech32m is expected to be used for them, so this shouldn't
-  affect any production systems, but may be observed on other networks where such
-  addresses already have meaning (like signet). (#20861)
-
-- The `getpeerinfo` RPC returns two new boolean fields, `bip152_hb_to` and
-  `bip152_hb_from`, that respectively indicate whether we selected a peer to be
-  in compact blocks high-bandwidth mode or whether a peer selected us as a
-  compact blocks high-bandwidth peer. High-bandwidth peers send new block
-  announcements via a `cmpctblock` message rather than the usual inv/headers
-  announcements. See BIP 152 for more details. (#19776)
-
-- `getpeerinfo` no longer returns the following fields: `addnode`, `banscore`,
-  and `whitelisted`, which were previously deprecated in 0.21. Instead of
-  `addnode`, the `connection_type` field returns manual. Instead of
-  `whitelisted`, the `permissions` field indicates if the peer has special
-  privileges. The `banscore` field has simply been removed. (#20755)
-
-- The following RPCs:  `gettxout`, `getrawtransaction`, `decoderawtransaction`,
-  `decodescript`, `gettransaction`, and REST endpoints: `/rest/tx`,
-  `/rest/getutxos`, `/rest/block` deprecated the following fields (which are no
-  longer returned in the responses by default): `addresses`, `reqSigs`.
-  The `-deprecatedrpc=addresses` flag must be passed for these fields to be
-  included in the RPC response. This flag/option will be available only for this major release, after which
-  the deprecation will be removed entirely. Note that these fields are attributes of
-  the `scriptPubKey` object returned in the RPC response. However, in the response
-  of `decodescript` these fields are top-level attributes, and included again as attributes
-  of the `scriptPubKey` object. (#20286)
-
-- When creating a hex-encoded bitcoin transaction using the `bitcoin-tx` utility
-  with the `-json` option set, the following fields: `addresses`, `reqSigs` are no longer
-  returned in the tx output of the response. (#20286)
-
-- The `listbanned` RPC now returns two new numeric fields: `ban_duration` and `time_remaining`.
-  Respectively, these new fields indicate the duration of a ban and the time remaining until a ban expires,
-  both in seconds. Additionally, the `ban_created` field is repositioned to come before `banned_until`. (#21602)
-
-- The `getnodeaddresses` RPC now returns a "network" field indicating the
-  network type (ipv4, ipv6, onion, or i2p) for each address.  (#21594)
-
-- `getnodeaddresses` now also accepts a "network" argument (ipv4, ipv6, onion,
-  or i2p) to return only addresses of the specified network.  (#21843)
-
-- The `testmempoolaccept` RPC now accepts multiple transactions (still experimental at the moment,
-  API may be unstable). This is intended for testing transaction packages with dependency
-  relationships; it is not recommended for batch-validating independent transactions. In addition to
-  mempool policy, package policies apply: the list cannot contain more than 25 transactions or have a
-  total size exceeding 101K virtual bytes, and cannot conflict with (spend the same inputs as) each other or
-  the mempool, even if it would be a valid BIP125 replace-by-fee. There are some known limitations to
-  the accuracy of the test accept: it's possible for `testmempoolaccept` to return "allowed"=True for a
-  group of transactions, but "too-long-mempool-chain" if they are actually submitted. (#20833)
-
-- `addmultisigaddress` and `createmultisig` now support up to 20 keys for
-  Segwit addresses. (#20867)
-
-Changes to Wallet or GUI related RPCs can be found in the GUI or Wallet section below.
-
 New RPCs
 --------
 
@@ -146,48 +69,15 @@ Build System
 New settings
 ------------
 
-- The `-natpmp` option has been added to use NAT-PMP to map the listening port.
-  If both UPnP and NAT-PMP are enabled, a successful allocation from UPnP
-  prevails over one from NAT-PMP. (#18077)
-
 Updated settings
 ----------------
 
-Changes to Wallet or GUI related settings can be found in the GUI or Wallet section below.
-
-- Passing an invalid `-rpcauth` argument now cause bitcoind to fail to start.  (#20461)
-
 Tools and Utilities
 -------------------
 
-- A new CLI `-addrinfo` command returns the number of addresses known to the
-  node per network type (including Tor v2 versus v3) and total. This can be
-  useful to see if the node knows enough addresses in a network to use options
-  like `-onlynet=<network>` or to upgrade to this release of Bitcoin Core 22.0
-  that supports Tor v3 only.  (#21595)
-
-- A new `-rpcwaittimeout` argument to `bitcoin-cli` sets the timeout
-  in seconds to use with `-rpcwait`. If the timeout expires,
-  `bitcoin-cli` will report a failure. (#21056)
-
 Wallet
 ------
 
-- A new `listdescriptors` RPC is available to inspect the contents of descriptor-enabled wallets.
-  The RPC returns public versions of all imported descriptors, including their timestamp and flags.
-  For ranged descriptors, it also returns the range boundaries and the next index to generate addresses from. (#20226)
-
-- The `bumpfee` RPC is not available with wallets that have private keys
-  disabled. `psbtbumpfee` can be used instead. (#20891)
-
-- The `fundrawtransaction`, `send` and `walletcreatefundedpsbt` RPCs now support an `include_unsafe` option
-  that when `true` allows using unsafe inputs to fund the transaction.
-  Note that the resulting transaction may become invalid if one of the unsafe inputs disappears.
-  If that happens, the transaction must be funded with different inputs and republished. (#21359)
-
-- We now support up to 20 keys in `multi()` and `sortedmulti()` descriptors
-  under `wsh()`. (#20867)
-
 GUI changes
 -----------
 
@@ -199,19 +89,6 @@ RPC
 
 - `getblockchaininfo` now returns a new `time` field, that provides the chain tip time. (#22407)
 
-- The RPC server can process a limited number of simultaneous RPC requests.
-  Previously, if this limit was exceeded, the RPC server would respond with
-  [status code 500 (`HTTP_INTERNAL_SERVER_ERROR`)](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#5xx_server_errors).
-  Now it returns status code 503 (`HTTP_SERVICE_UNAVAILABLE`). (#18335)
-
-- Error codes have been updated to be more accurate for the following error cases (#18466):
-  - `signmessage` now returns RPC_INVALID_ADDRESS_OR_KEY (-5) if the
-    passed address is invalid. Previously returned RPC_TYPE_ERROR (-3).
-  - `verifymessage` now returns RPC_INVALID_ADDRESS_OR_KEY (-5) if the
-    passed address is invalid. Previously returned RPC_TYPE_ERROR (-3).
-  - `verifymessage` now returns RPC_TYPE_ERROR (-3) if the passed signature
-    is malformed. Previously returned RPC_INVALID_ADDRESS_OR_KEY (-5).
-
 Tests
 -----