Now that 0.18 branch has been split off, master is 0.18.99 (pre-0.19).
Also clean out release notes.
Tree-SHA512: ed5ca8bed37027aa852ba16f3f1e7fcd4ebaf74fa77a2a265cb33a9c710511019c577fae7a3b1e33259e245274d5cd4601d4774948396d0cf299b38ba634346a
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
------------
------------
- 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
Low-level changes
=================
=================
RPC
Example item
---
------------
- 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
Wladimir J. van der Laan
6 years ago