You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
175 lines
6.9 KiB
175 lines
6.9 KiB
*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)
|
|
|
|
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)
|
|
|
|
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/).
|