aboutsummaryrefslogtreecommitdiff
path: root/doc/release-notes.md
diff options
context:
space:
mode:
authorMarcoFalke <falke.marco@gmail.com>2021-03-29 11:35:55 +0200
committerMarcoFalke <falke.marco@gmail.com>2021-03-29 15:57:14 +0200
commit1111896eb7865a7bc474ee2aa338c97c22a66c14 (patch)
treed507efbe3f83bf943214ec9d98ab560f15e4cdd2 /doc/release-notes.md
parentfaeba9819d81e0f41756a45db55030ec3ba9f044 (diff)
downloadbitcoin-1111896eb7865a7bc474ee2aa338c97c22a66c14.tar.xz
doc: Merge release notes
Diffstat (limited to 'doc/release-notes.md')
-rw-r--r--doc/release-notes.md41
1 files changed, 38 insertions, 3 deletions
diff --git a/doc/release-notes.md b/doc/release-notes.md
index 0f36466985..334dfa80a4 100644
--- a/doc/release-notes.md
+++ b/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
- point the deprecation will be removed entirely. Note that these fields are attributes of
+ 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)
@@ -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
-----