phantom/bitcoin
1
0
Fork 0
mirror of https://github.com/bitcoin/bitcoin.git synced 2025-01-19 07:59:20 -03:00
Code Issues Projects Releases Packages Wiki Activity Actions
bitcoin/doc/release-notes.md
MarcoFalke f6c44e999b
Merge #21602: rpc: add additional ban time fields to listbanned 
d3b0b08b0f doc: release notes for new listbanned fields (Jarol Rodriguez)
60290d3f5e test: increase listbanned unit test coverage (Jon Atack)
3e978d1a5d rpc: add time_remaining field to listbanned (Jarol Rodriguez)
5456b34531 rpc: add ban_duration field to listbanned (Jarol Rodriguez)
c95c61657a doc: improve listbanned help (Jarol Rodriguez)
dd3c8eaa33 rpc: swap position of banned_until and ban_created fields (Jarol Rodriguez)

Pull request description:

  This PR adds a `ban_duration` and `time_remaining` field to the `listbanned` RPC command. Thanks to jonatack, this PR also expands the `listbanned` test coverage to include these new fields

  It's useful to keep track of `ban_duration` as this is another data point on which to sort banned peers. I found this helpful in adding additional context columns to the GUI `bantablemodel` as part of a follow-up PR. As [suggested](https://github.com/bitcoin/bitcoin/pull/21602#issuecomment-813486134) by jonatack, `time_remaining` is another useful user-centric data point.

  Since a ban always expires after its created, the `ban_created` field is now placed before the `banned_until` field. This new ordering is more logical.

  This PR also improves the `help listbanned` output by providing additional context to the descriptions of the `address`, `ban_created`, and `banned_until` fields.

  **Master: listbanned**
  ```
  [
    {
      "address": "1.2.3.4/32",
      "banned_until": 1617691101,
      "ban_created": 1617604701
    },
    {
      "address": "135.181.41.129/32",
      "banned_until": 1649140716,
      "ban_created": 1617604716
    }
  ]
  ```

  **PR: listbanned**
  ```
  [
    {
      "address": "1.2.3.4/32",
      "ban_created": 1617775773,
      "banned_until": 1617862173,
      "ban_duration": 86400,
      "time_remaining": 86392
    },
    {
      "address": "3.114.211.172/32",
      "ban_created": 1617753165,
      "banned_until": 1618357965,
      "ban_duration": 604800,
      "time_remaining": 582184
    }
  ]
  ```

ACKs for top commit:
  jonatack:
    re-ACK d3b0b08b0f
  hebasto:
    ACK d3b0b08b0f, tested on Linux Mint 20.1 (x86_64).
  MarcoFalke:
    review ACK d3b0b08b0f 🕙

Tree-SHA512: 5b83ed2483344e546d57e43adc8a1ed7a1fff292124b14c86ca3a1aa2aec8b0f7198212fabff2c5145e7f726ca04ae567fe667b141254c7519df290cf63774e5
2021-04-11 13:36:29 +02:00

181 lines
7.4 KiB
Markdown
Raw Blame History

*After branching off for a major version release of Bitcoin Core, use this
template to create the initial release notes draft.*
*The release notes draft is a temporary file that can be added to by anyone. See
[/doc/developer-notes.md#release-notes](/doc/developer-notes.md#release-notes)
for the process.*
*Create the draft, named* "*version* Release Notes Draft"
*(e.g. "0.20.0 Release Notes Draft"), as a collaborative wiki in:*
https://github.com/bitcoin-core/bitcoin-devwiki/wiki/
*Before the final release, move the notes back to this git repository.*
*version* Release Notes Draft
===============================
Bitcoin Core version *version* is now available from:
<https://bitcoincore.org/bin/bitcoin-core-*version*/>
This release includes new features, various bug fixes and performance
improvements, as well as updated translations.
Please report bugs using the issue tracker at GitHub:
<https://github.com/bitcoin/bitcoin/issues>
To receive security and update notifications, please subscribe to:
<https://bitcoincore.org/en/list/announcements/join/>
How to Upgrade
==============
If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes in some cases), then run the
installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
or `bitcoind`/`bitcoin-qt` (on Linux).
Upgrading directly from a version of Bitcoin Core that has reached its EOL is
possible, but it might take some time if the data directory needs to be migrated. Old
wallet versions of Bitcoin Core are generally supported.
Compatibility
==============
Bitcoin Core is supported and extensively tested on operating systems
using the Linux kernel, macOS 10.14+, and Windows 7 and newer. Bitcoin
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
-----------------------
- 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)
Changes to Wallet or GUI related RPCs can be found in the GUI or Wallet section below.
New RPCs
--------
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)
- The `getnodeaddresses` RPC now returns a "network" field indicating the
network type (ipv4, ipv6, onion, or i2p) for each address. (#21594)
Tools and Utilities
-------------------
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)
GUI changes
-----------
Low-level changes
=================
RPC
---
- 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
-----
Credits
=======
Thanks to everyone who directly contributed to this release:
As well as to everyone that helped with translations on
[Transifex](https://www.transifex.com/bitcoin/bitcoin/).
Reference in a new issue View git blame Copy permalink