diff options
| -rw-r--r-- | configure.ac | 2 | ||||
| -rw-r--r-- | doc/release-notes.md | 304 |
2 files changed, 4 insertions, 302 deletions
diff --git a/configure.ac b/configure.ac index dec6d4fac3..984c595ead 100644 --- a/configure.ac +++ b/configure.ac @@ -1,7 +1,7 @@ dnl require autoconf 2.60 (AS_ECHO/AS_ECHO_N) AC_PREREQ([2.60]) define(_CLIENT_VERSION_MAJOR, 0) -define(_CLIENT_VERSION_MINOR, 17) +define(_CLIENT_VERSION_MINOR, 18) define(_CLIENT_VERSION_REVISION, 99) define(_CLIENT_VERSION_BUILD, 0) define(_CLIENT_VERSION_RC, 0) diff --git a/doc/release-notes.md b/doc/release-notes.md index 03b3121ecb..ebcdcda306 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -66,313 +66,15 @@ platform. Notable changes =============== -Mining ------- - -- Calls to `getblocktemplate` will fail if the segwit rule is not specified. - Calling `getblocktemplate` without segwit specified is almost certainly - a misconfiguration since doing so results in lower rewards for the miner. - Failed calls will produce an error message describing how to enable the - segwit rule. - -Configuration option changes ----------------------------- - -- A warning is printed if an unrecognized section name is used in the - configuration file. Recognized sections are `[test]`, `[main]`, and - `[regtest]`. - -- Four new options are available for configuring the maximum number of - messages that ZMQ will queue in memory (the "high water mark") before - dropping additional messages. The default value is 1,000, the same as - was used for previous releases. See the [ZMQ - documentation](https://github.com/bitcoin/bitcoin/blob/master/doc/zmq.md#usage) - for details. - -- The `enablebip61` option (introduced in Bitcoin Core 0.17.0) is - used to toggle sending of BIP 61 reject messages. Reject messages have no use - case on the P2P network and are only logged for debugging by most network - nodes. The option will now by default be off for improved privacy and security - as well as reduced upload usage. The option can explicitly be turned on for - local-network debugging purposes. - -- The `rpcallowip` option can no longer be used to automatically listen - on all network interfaces. Instead, the `rpcbind` parameter must also - be used to specify the IP addresses to listen on. Listening for RPC - commands over a public network connection is insecure and should be - disabled, so a warning is now printed if a user selects such a - configuration. If you need to expose RPC in order to use a tool - like Docker, ensure you only bind RPC to your localhost, e.g. `docker - run [...] -p 127.0.0.1:8332:8332` (this is an extra `:8332` over the - normal Docker port specification). - -- The `rpcpassword` option now causes a startup error if the password - set in the configuration file contains a hash character (#), as it's - ambiguous whether the hash character is meant for the password or as a - comment. - -- The `whitelistforcerelay` option is used to relay transactions from - whitelisted peers even when not accepted to the mempool. This option now - defaults to being off, so that changes in policy and disconnect/ban behavior - will not cause a node that is whitelisting another to be dropped by peers. - Users can still explicitly enable this behavior with the command line option - (and may want to consider [contacting](https://bitcoincore.org/en/contact/) - the Bitcoin Core project to let us know about their - use-case, as this feature could be deprecated in the future). - -Documentation -------------- - -- A new short - [document](https://github.com/bitcoin/bitcoin/blob/master/doc/JSON-RPC-interface.md) - about the JSON-RPC interface describes cases where the results of an - RPC might contain inconsistencies between data sourced from different - subsystems, such as wallet state and mempool state. A note is added - to the [REST interface documentation](https://github.com/bitcoin/bitcoin/blob/master/doc/REST-interface.md) - indicating that the same rules apply. - -- Further information is added to the [JSON-RPC - documentation](https://github.com/bitcoin/bitcoin/blob/master/doc/JSON-RPC-interface.md) - about how to secure this interface. - -- A new [document](https://github.com/bitcoin/bitcoin/blob/master/doc/bitcoin-conf.md) - about the `bitcoin.conf` file describes how to use it to configure - Bitcoin Core. - -- A new document introduces Bitcoin Core's BIP174 - [Partially-Signed Bitcoin Transactions (PSBT)](https://github.com/bitcoin/bitcoin/blob/master/doc/psbt.md) - interface, which is used to allow multiple programs to collaboratively - work to create, sign, and broadcast new transactions. This is useful - for offline (cold storage) wallets, multisig wallets, coinjoin - implementations, and many other cases where two or more programs need - to interact to generate a complete transaction. - -- The [output script descriptor](https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md) - documentation has been updated with information about new features in - this still-developing language for describing the output scripts that - a wallet or other program wants to receive notifications for, such as - which addresses it wants to know received payments. The language is - currently used in the `scantxoutset` RPC and is expected to be adapted - to other RPCs and to the underlying wallet structure. - -Build system changes --------------------- - -- A new `--disable-bip70` option may be passed to `./configure` to - prevent Bitcoin-Qt from being built with support for the BIP70 payment - protocol or from linking libssl. As the payment protocol has exposed - Bitcoin Core to libssl vulnerabilities in the past, builders who don't - need BIP70 support are encouraged to use this option to reduce their - exposure to future vulnerabilities. - -Deprecated or removed RPCs --------------------------- - -- The `signrawtransaction` RPC is removed after being deprecated and - hidden behind a special configuration option in version 0.17.0. - -- The 'account' API is removed after being deprecated in v0.17. The - 'label' API was introduced in v0.17 as a replacement for accounts. - See the [release notes from v0.17](https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.17.0.md#label-and-account-apis-for-wallet) - for a full description of the changes from the 'account' API to the - 'label' API. - -- The `addwitnessaddress` RPC is removed after being deprecated in - version 0.13.0. - -- The wallet's `generate` RPC method is deprecated and will be fully - removed in a subsequent major version. This RPC is only used for - testing, but its implementation reached across multiple subsystems - (wallet and mining), so it is being deprecated to simplify the - wallet-node interface. Projects that are using `generate` for testing - purposes should transition to using the `generatetoaddress` RPC, which - does not require or use the wallet component. Calling - `generatetoaddress` with an address returned by the `getnewaddress` - RPC gives the same functionality as the old `generate` RPC. To - continue using `generate` in this version, restart bitcoind with the - `-deprecatedrpc=generate` configuration option. - -New RPCs --------- - -- The `getnodeaddresses` RPC returns peer addresses known to this - node. It may be used to find nodes to connect to without using a DNS - seeder. - -- The `listwalletdir` RPC returns a list of wallets in the wallet - directory (either the default wallet directory or the directory - configured by the `-walletdir` parameter). - -- The `getrpcinfo` returns runtime details of the RPC server. At the - moment, it returns an array of the currently active commands and how - long they've been running. - -Updated RPCs ------------- - -Note: some low-level RPC changes mainly useful for testing are described -in the Low-level Changes section below. - -- The `getpeerinfo` RPC now returns an additional `minfeefilter` field - set to the peer's BIP133 fee filter. You can use this to detect that - you have peers that are willing to accept transactions below the - default minimum relay fee. - -- The mempool RPCs, such as `getrawmempool` with `verbose=true`, now - return an additional "bip125-replaceable" value indicating whether the - transaction (or its unconfirmed ancestors) opts-in to asking nodes and - miners to replace it with a higher-feerate transaction spending any of - the same inputs. - -- The `settxfee` RPC previously silently ignored attempts to set the fee - below the allowed minimums. It now prints a warning. The special - value of "0" may still be used to request the minimum value. - -- The `getaddressinfo` RPC now provides an `ischange` field indicating - whether the wallet used the address in a change output. - -- The `importmulti` RPC has been updated to support P2WSH, P2WPKH, - P2SH-P2WPKH, and P2SH-P2WSH. Requests for P2WSH and P2SH-P2WSH accept - an additional `witnessscript` parameter. - -- The `importmulti` RPC now returns an additional `warnings` field for - each request with an array of strings explaining when fields are being - ignored or are inconsistent, if there are any. - -- The `getaddressinfo` RPC now returns an additional `solvable` boolean - field when Bitcoin Core knows enough about the address's scriptPubKey, - optional redeemScript, and optional witnessScript in order for the - wallet to be able to generate an unsigned input spending funds sent to - that address. - -- The `getaddressinfo`, `listunspent`, and `scantxoutset` RPCs now - return an additional `desc` field that contains an output descriptor - containing all key paths and signing information for the address - (except for the private key). The `desc` field is only returned for - `getaddressinfo` and `listunspent` when the address is solvable. - -- The `importprivkey` RPC will preserve previously-set labels for - addresses or public keys corresponding to the private key being - imported. For example, if you imported a watch-only address with the - label "cold wallet" in earlier releases of Bitcoin Core, subsequently - importing the private key would default to resetting the address's - label to the default empty-string label (""). In this release, the - previous label of "cold wallet" will be retained. If you optionally - specify any label besides the default when calling `importprivkey`, - the new label will be applied to the address. - -- See the [Mining](#mining) section for changes to `getblocktemplate`. - -- The `getmininginfo` RPC now omits `currentblockweight` and `currentblocktx` - when a block was never assembled via RPC on this node. - -- The `getrawtransaction` RPC & REST endpoints no longer check the - unspent UTXO set for a transaction. The remaining behaviors are as - follows: 1. If a blockhash is provided, check the corresponding block. - 2. If no blockhash is provided, check the mempool. 3. If no blockhash - is provided but txindex is enabled, also check txindex. - -- The `unloadwallet` RPC is now synchronous, meaning it will not return - until the wallet is fully unloaded. - -REST changes +Example item ------------ -- A new `/rest/blockhashbyheight/` endpoint is added for fetching the - hash of the block in the current best blockchain based on its height - (how many blocks it is after the Genesis Block). - -Graphical User Interface (GUI) ------------------------------- - -- A new Window menu is added alongside the existing File, Settings, and - Help menus. Several items from the other menus that opened new - windows have been moved to this new Window menu. - -- In the Send tab, the checkbox for "pay only the required fee" - has been removed. Instead, the user can simply decrease the value in - the Custom Feerate field all the way down to the node's configured - minimum relay fee. - -- In the Overview tab, the watch-only balance will be the only - balance shown if the wallet was created using the `createwallet` RPC - and the `disable_private_keys` parameter was set to true. - -- The launch-on-startup option is no longer available on macOS if - compiled with macosx min version greater than 10.11 (use - CXXFLAGS="-mmacosx-version-min=10.11" - CFLAGS="-mmacosx-version-min=10.11" for setting the deployment - sdk version) - -Tools ----- - -- A new `bitcoin-wallet` tool is now distributed alongside Bitcoin - Core's other executables. Without needing to use any RPCs, this tool - can currently create a new wallet file or display some basic - information about an existing wallet, such as whether the wallet is - encrypted, whether it uses an HD seed, how many transactions it - contains, and how many address book entries it has. Low-level changes ================= -RPC ---- - -- The `submitblock` RPC previously returned the reason a rejected block - was invalid the first time it processed that block but returned a - generic "duplicate" rejection message on subsequent occasions it - processed the same block. It now always returns the fundamental - reason for rejecting an invalid block and only returns "duplicate" for - valid blocks it has already accepted. - -- A new `submitheader` RPC allows submitting block headers independently - from their block. This is likely only useful for testing. - -Configuration -------------- - -- The `-usehd` configuration option was removed in version 0.16. From - that version onwards, all new wallets created are hierarchical - deterministic wallets. This release makes specifying `-usehd` an - invalid configuration option. - -Network -------- - -- This release allows peers that your node automatically disconnected - for misbehavior (e.g. sending invalid data) to reconnect to your node - if you have unused incoming connection slots. If your slots fill up, - a misbehaving node will be disconnected to make room for nodes without - a history of problems (unless the misbehaving node helps your node in - some other way, such as by connecting to a part of the Internet from - which you don't have many other peers). Previously, Bitcoin Core - banned the IP addresses of misbehaving peers for a period of time - (default of 1 day); this was easily circumvented by attackers with - multiple IP addresses. If you manually ban a peer, such as by using - the `setban` RPC, all connections from that peer will still be - rejected. - -Security --------- - -- This release changes the Random Number Generator (RNG) used from - OpenSSL to Bitcoin Core's own implementation, although entropy - gathered by Bitcoin Core is fed out to OpenSSL and then read back in - when the program needs strong randomness. This moves Bitcoin Core a - little closer to no longer needing to depend on OpenSSL, a dependency - that has caused security issues in the past. - -Changes for particular platforms --------------------------------- - -- On macOS, Bitcoin Core now opts out of application CPU throttling - ("app nap") during initial blockchain download, when catching up from - over 100 blocks behind the current chain tip, or when reindexing chain - data. This helps prevent these operations from taking an excessively - long time because the operating system is attempting to conserve - power. +Example item +------------ Credits ======= |