forked from bitcoin/bitcoin
-
Notifications
You must be signed in to change notification settings - Fork 22
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
2 changed files
with
224 additions
and
10 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,221 @@ | ||
| 22.0 Release Notes | ||
| ================== | ||
|
|
||
| Groestlcoin Core version 22.0 is now available from: | ||
|
|
||
| <https://www.groestlcoin.org/groestlcoin-core-wallet/> | ||
|
|
||
| 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/groestlcoin/groestlcoin/issues> | ||
|
|
||
| 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/Groestlcoin-Qt` (on Mac) | ||
| or `groestlcoind`/`groestlcoin-qt` (on Linux). | ||
|
|
||
| Upgrading directly from a version of Groestlcoin 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 Groestlcoin Core are generally supported. | ||
|
|
||
| Compatibility | ||
| ============== | ||
|
|
||
| Groestlcoin Core is supported and extensively tested on operating systems | ||
| using the Linux kernel, macOS 10.14+, and Windows 7 and newer. Groestlcoin | ||
| Core should also work on most other Unix-like systems but is not as | ||
| frequently tested on them. It is not recommended to use Groestlcoin Core on | ||
| unsupported systems. | ||
|
|
||
| From Groestlcoin Core 22.0 onwards, macOS versions earlier than 10.14 are no longer supported. | ||
|
|
||
| Notable changes | ||
| =============== | ||
|
|
||
| P2P and network changes | ||
| ----------------------- | ||
| - Added support for running Groestlcoin Core as an | ||
| [I2P (Invisible Internet Project)](https://en.wikipedia.org/wiki/I2P) service | ||
| and connect to such services. See [i2p.md](https://github.com/groestlcoin/groestlcoin/blob/22.0.0/doc/i2p.md) for details. | ||
| - This release removes support for Tor version 2 hidden services in favor of Tor | ||
| v3 only, as the Tor network [dropped support for Tor | ||
| v2](https://blog.torproject.org/v2-deprecation-timeline) with the release of | ||
| Tor version 0.4.6. Henceforth, Groestlcoin Core ignores Tor v2 addresses; it | ||
| neither rumors them over the network to other peers, nor stores them in memory | ||
| or to `peers.dat`. | ||
|
|
||
| - Added NAT-PMP port mapping support via | ||
| [`libnatpmp`](https://miniupnp.tuxfamily.org/libnatpmp.html). | ||
|
|
||
| New and 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 | ||
| (as will happen 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). | ||
|
|
||
| - 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. | ||
|
|
||
| - `getpeerinfo` no longer returns the following fields: `addnode`, `banscore`, | ||
| and `whitelisted`, which were previously deprecated in 2.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. | ||
|
|
||
| - 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. | ||
|
|
||
| - When creating a hex-encoded groestlcoin transaction using the `groestlcoin-tx` utility | ||
| with the `-json` option set, the following fields: `addresses`, `reqSigs` are no longer | ||
| returned in the tx output of the response. | ||
|
|
||
| - 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`. | ||
|
|
||
| - The `setban` RPC can ban onion addresses again. This fixes a regression introduced in version 2.21.0. | ||
|
|
||
| - The `getnodeaddresses` RPC now returns a "network" field indicating the | ||
| network type (ipv4, ipv6, onion, or i2p) for each address. | ||
|
|
||
| - `getnodeaddresses` now also accepts a "network" argument (ipv4, ipv6, onion, | ||
| or i2p) to return only addresses of the specified network. | ||
|
|
||
| - The `testmempoolaccept` RPC now accepts multiple transactions (still experimental at the moment, | ||
| API may be unstable). This is intended for testing transaction packages with dependency | ||
| relationships; it is not recommended for batch-validating independent transactions. In addition to | ||
| mempool policy, package policies apply: the list cannot contain more than 25 transactions or have a | ||
| total size exceeding 101K virtual bytes, and cannot conflict with (spend the same inputs as) each other or | ||
| the mempool, even if it would be a valid BIP125 replace-by-fee. There are some known limitations to | ||
| the accuracy of the test accept: it's possible for `testmempoolaccept` to return "allowed"=True for a | ||
| group of transactions, but "too-long-mempool-chain" if they are actually submitted. | ||
|
|
||
| - `addmultisigaddress` and `createmultisig` now support up to 20 keys for | ||
| Segwit addresses. | ||
|
|
||
| Changes to Wallet or GUI related RPCs can be found in the GUI or Wallet section below. | ||
|
|
||
| Build System | ||
| ------------ | ||
|
|
||
| - Release binaries are now produced using the new `guix`-based build system. | ||
| The [/doc/release-process.md](/doc/release-process.md) document has been updated accordingly. | ||
|
|
||
| Files | ||
| ----- | ||
|
|
||
| - The list of banned hosts and networks (via `setban` RPC) is now saved on disk | ||
| in JSON format in `banlist.json` instead of `banlist.dat`. `banlist.dat` is | ||
| only read on startup if `banlist.json` is not present. Changes are only written to the new | ||
| `banlist.json`. A future version of Groestlcoin Core may completely ignore | ||
| `banlist.dat`. | ||
|
|
||
| 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. | ||
|
|
||
| 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 groestlcoind to fail to start. | ||
|
|
||
| Tools and Utilities | ||
| ------------------- | ||
|
|
||
| - A new CLI `-addrinfo` command returns the number of addresses known to the | ||
| node per network type (including Tor v2 versus v3) and total. This can be | ||
| useful to see if the node knows enough addresses in a network to use options | ||
| like `-onlynet=<network>` or to upgrade to this release of Groestlcoin Core 22.0 | ||
| that supports Tor v3 only. | ||
|
|
||
| - A new `-rpcwaittimeout` argument to `groestlcoin-cli` sets the timeout | ||
| in seconds to use with `-rpcwait`. If the timeout expires, | ||
| `groestlcoin-cli` will report a failure. | ||
|
|
||
| Wallet | ||
| ------ | ||
|
|
||
| - External signers such as hardware wallets can now be used through the new RPC methods `enumeratesigners` and `displayaddress`. Support is also added to the `send` RPC call. This feature is experimental. See [external-signer.md](https://github.com/groestlcoin/groestlcoin/blob/22.0.0/doc/external-signer.md) for details. | ||
|
|
||
| - 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. | ||
|
|
||
| - The `bumpfee` RPC is not available with wallets that have private keys | ||
| disabled. `psbtbumpfee` can be used instead. | ||
|
|
||
| - The `fundrawtransaction`, `send` and `walletcreatefundedpsbt` RPCs now support an `include_unsafe` option | ||
| that when `true` allows using unsafe inputs to fund the transaction. | ||
| Note that the resulting transaction may become invalid if one of the unsafe inputs disappears. | ||
| If that happens, the transaction must be funded with different inputs and republished. | ||
|
|
||
| - We now support up to 20 keys in `multi()` and `sortedmulti()` descriptors | ||
| under `wsh()`. | ||
|
|
||
| - Taproot descriptors can be imported into the wallet only after activation has occurred on the network (e.g. mainnet, testnet, signet) in use. See [descriptors.md](https://github.com/groestlcoin/groestlcoin/blob/22.0.0/doc/descriptors.md) for supported descriptors. | ||
|
|
||
| GUI changes | ||
| ----------- | ||
|
|
||
| - External signers such as hardware wallets can now be used. These require an external tool such as [HWI](https://github.com/groestlcoin/HWI) to be installed and configured under Options -> Wallet. When creating a new wallet a new option "External signer" will appear in the dialog. If the device is detected, its name is suggested as the wallet name. The watch-only keys are then automatically imported. Receive addresses can be verified on the device. The send dialog will automatically use the connected device. This feature is experimental and the UI may freeze for a few seconds when performing these actions. | ||
|
|
||
| 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`). | ||
|
|
||
| - Error codes have been updated to be more accurate for the following error cases: | ||
| - `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/). |