diff options
author | MarcoFalke <falke.marco@gmail.com> | 2021-03-29 11:35:55 +0200 |
---|---|---|
committer | MarcoFalke <falke.marco@gmail.com> | 2021-03-29 15:57:14 +0200 |
commit | 1111896eb7865a7bc474ee2aa338c97c22a66c14 (patch) | |
tree | d507efbe3f83bf943214ec9d98ab560f15e4cdd2 /doc/release-notes.md | |
parent | faeba9819d81e0f41756a45db55030ec3ba9f044 (diff) |
doc: Merge release notes
Diffstat (limited to 'doc/release-notes.md')
-rw-r--r-- | doc/release-notes.md | 41 |
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 ----- |