doc: Merge release notes

doc/release-notes-18077.md

@@ -1,10 +0,0 @@
-P2P and network changes
------------------------
-
-- Added NAT-PMP port mapping support via [`libnatpmp`](https://miniupnp.tuxfamily.org/libnatpmp.html)
-
-Command-line options
---------------------
-
-- 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.

doc/release-notes-18466.md

@@ -1,10 +0,0 @@
-Low-level RPC changes
----------------------
-
-- 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).

doc/release-notes-19776.md

@@ -1,9 +0,0 @@
-Updated RPCs
-------------
-
-- 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)

doc/release-notes-20861.md

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

doc/release-notes.md

@@ -59,8 +59,30 @@ Notable changes
 P2P and network changes
 -----------------------
 
+- 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
@@ -72,8 +94,8 @@ Updated RPCs
   `/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 until v23, at which
+  included in the RPC response. This flag/option will be available only for this major release, after which
-  point the deprecation will be removed entirely. Note that these fields are attributes of
+  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)
@@ -93,6 +115,10 @@ 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
 ----------------
 
@@ -121,11 +147,20 @@ Low-level changes
 
 RPC
 ---
+
 - The RPC server can process a limited number of simultaneous RPC requests.
-  Previously, if this limit was exceeded, `bitcoind` would respond with
+  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
 -----