Inside Bitcoin

251Note: some low-level RPC changes mainly useful for testing are described
252in the Low-level Changes section below.
253
254- `getpeerinfo` now returns an additional `minfeefilter` field set to
255  the peer's BIP133 fee filter.  You can use this to detect that you
256  have peers that are willing to accept transactions below the default
257  minimum relay fee.
258
259- The mempool RPCs, such as `getrawmempool` with `verbose=true`, now
260  return an additional "bip125-replaceable" value indicating whether the
261  transaction (or its unconfirmed ancestors) opts-in to asking nodes and
262  miners to replace it with a higher-feerate transaction spending any of
263  the same inputs.
264
265- `settxfee` previously silently ignored attempts to set the fee below
266  the allowed minimums.  It now prints a warning.  The special value of
267  "0" may still be used to request the minimum value.
268
269- `getaddressinfo` now provides an `ischange` field indicating whether
270  the wallet used the address in a change output.
271
272- `importmulti` has been updated to support P2WSH, P2WPKH, P2SH-P2WPKH,
273  and P2SH-P2WSH. Requests for P2WSH and P2SH-P2WSH accept an additional
274  `witnessscript` parameter.
275
276- `importmulti` now returns an additional `warnings` field for each
277  request with an array of strings explaining when fields are being
278  ignored or are inconsistent, if there are any.
279
280- `getaddressinfo` now returns an additional `solvable` boolean field
281  when Bitcoin Core knows enough about the address's scriptPubKey,
282  optional redeemScript, and optional witnessScript in order for the
283  wallet to be able to generate an unsigned input spending funds sent to
284  that address.
285
286- The `getaddressinfo`, `listunspent`, and `scantxoutset` RPCs now
287  return an additional `desc` field that contains an output descriptor
288  containing all key paths and signing information for the address
289  (except for the private key).  The `desc` field is only returned for
290  `getaddressinfo` and `listunspent` when the address is solvable.
291
292- `importprivkey` will preserve previously-set labels for addresses or
293  public keys corresponding to the private key being imported.  For
294  example, if you imported a watch-only address with the label "cold
295  wallet" in earlier releases of Bitcoin Core, subsequently importing
296  the private key would default to resetting the address's label to the
297  default empty-string label ("").  In this release, the previous label
298  of "cold wallet" will be retained.  If you optionally specify any
299  label besides the default when calling `importprivkey`, the new label
300  will be applied to the address.
301
302- See the [Mining](#mining) section for changes to `getblocktemplate`.
303
304- `getmininginfo` now omits `currentblockweight` and `currentblocktx`
305  when a block was never assembled via RPC on this node.
306
307- The `getrawtransaction` RPC & REST endpoints no longer check the
308  unspent UTXO set for a transaction. The remaining behaviors are as
309  follows: 1. If a blockhash is provided, check the corresponding block.
310  2. If no blockhash is provided, check the mempool. 3. If no blockhash
311  is provided but txindex is enabled, also check txindex.
312
313- `unloadwallet` is now synchronous, meaning it will not return until
314  the wallet is fully unloaded.
315
316- `importmulti` now supports importing of addresses from descriptors. A
317  "desc" parameter can be provided instead of the "scriptPubKey" in a
318  request, as well as an optional range for ranged descriptors to
319  specify the start and end of the range to import. Descriptors with key
320  origin information imported through `importmulti` will have their key
321  origin information stored in the wallet for use with creating PSBTs.
322  More information about descriptors can be found
323  [here](https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md).
324
325- `listunspent` has been modified so that it also returns
326  `witnessScript`, the witness script in the case of a P2WSH or
327  P2SH-P2WSH output.
328
329- `createwallet` now has an optional `blank` argument that can be used
330  to create a blank wallet. Blank wallets do not have any keys or HD
331  seed.  They cannot be opened in software older than 0.18. Once a blank
332  wallet has a HD seed set (by using `sethdseed`) or private keys,
333  scripts, addresses, and other watch only things have been imported,
334  the wallet is no longer blank and can be opened in 0.17.x. Encrypting
335  a blank wallet will also set a HD seed for it.
336
337Deprecated or removed RPCs
338--------------------------
339
340- `signrawtransaction` is removed after being deprecated and hidden
341  behind a special configuration option in version 0.17.0.
342
343- The 'account' API is removed after being deprecated in v0.17.  The
344  'label' API was introduced in v0.17 as a replacement for accounts.
345  See the [release notes from
346  v0.17](https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.17.0.md#label-and-account-apis-for-wallet)
347  for a full description of the changes from the 'account' API to the
348  'label' API.
349
350- `addwitnessaddress` is removed after being deprecated in version
351  0.16.0.
352
353- `generate` is deprecated and will be fully removed in a subsequent
354  major version.  This RPC is only used for testing, but its
355  implementation reached across multiple subsystems (wallet and mining),
356  so it is being deprecated to simplify the wallet-node interface.
357  Projects that are using `generate` for testing purposes should
358  transition to using the `generatetoaddress` RPC, which does not
359  require or use the wallet component. Calling `generatetoaddress` with
360  an address returned by the `getnewaddress` RPC gives the same
361  functionality as the old `generate` RPC.  To continue using `generate`
362  in this version, restart bitcoind with the `-deprecatedrpc=generate`
363  configuration option.
364
365- Be reminded that parts of the `validateaddress` command have been
366  deprecated and moved to `getaddressinfo`. The following deprecated
367  fields have moved to `getaddressinfo`: `ismine`, `iswatchonly`,
368  `script`, `hex`, `pubkeys`, `sigsrequired`, `pubkey`, `embedded`,
369  `iscompressed`, `label`, `timestamp`, `hdkeypath`, `hdmasterkeyid`.
370
371- The `addresses` field has been removed from the `validateaddress`
372  and `getaddressinfo` RPC methods.  This field was confusing since
373  it referred to public keys using their P2PKH address.  Clients
374  should use the `embedded.address` field for P2SH or P2WSH wrapped
375  addresses, and `pubkeys` for inspecting multisig participants.
376
377REST changes
378------------
379
380- A new `/rest/blockhashbyheight/` endpoint is added for fetching the
381  hash of the block in the current best blockchain based on its height
382  (how many blocks it is after the Genesis Block).
383
384Graphical User Interface (GUI)
385------------------------------
386
387- A new Window menu is added alongside the existing File, Settings, and
388  Help menus.  Several items from the other menus that opened new
389  windows have been moved to this new Window menu.
390
391- In the Send tab, the checkbox for "pay only the required fee" has been
392  removed.  Instead, the user can simply decrease the value in the
393  Custom Feerate field all the way down to the node's configured minimum
394  relay fee.
395
396- In the Overview tab, the watch-only balance will be the only balance
397  shown if the wallet was created using the `createwallet` RPC and the
398  `disable_private_keys` parameter was set to true.
399
400- The launch-on-startup option is no longer available on macOS if
401  compiled with macosx min version greater than 10.11 (use
402  CXXFLAGS="-mmacosx-version-min=10.11"
403  CFLAGS="-mmacosx-version-min=10.11" for setting the deployment sdk
404  version)
405
406Tools
407-----
408
409- A new `bitcoin-wallet` tool is now distributed alongside Bitcoin
410  Core's other executables.  Without needing to use any RPCs, this tool
411  can currently create a new wallet file or display some basic
412  information about an existing wallet, such as whether the wallet is
413  encrypted, whether it uses an HD seed, how many transactions it
414  contains, and how many address book entries it has.
415
416Planned changes
417===============
418
419This section describes planned changes to Bitcoin Core that may affect
420other Bitcoin software and services.
421
422- Since version 0.16.0, Bitcoin Core’s built-in wallet has defaulted to
423  generating P2SH-wrapped segwit addresses when users want to receive
424  payments. These addresses are backwards compatible with all
425  widely-used software.  Starting with Bitcoin Core 0.20 (expected about
426  a year after 0.18), Bitcoin Core will default to native segwit
427  addresses (bech32) that provide additional fee savings and other
428  benefits. Currently, many wallets and services already support sending
429  to bech32 addresses, and if the Bitcoin Core project sees enough
430  additional adoption, it will instead default to bech32 receiving
431  addresses in Bitcoin Core 0.19 (approximately November 2019).
432  P2SH-wrapped segwit addresses will continue to be provided if the user
433  requests them in the GUI or by RPC, and anyone who doesn’t want the
434  update will be able to configure their default address type.
435  (Similarly, pioneering users who want to change their default now may
436  set the `addresstype=bech32` configuration option in any Bitcoin Core
437  release from 0.16.0 up.)
438
439Deprecated P2P messages
440-----------------------
441
442- BIP 61 reject messages are now deprecated. Reject messages have no use
443  case on the P2P network and are only logged for debugging by most
444  network nodes. Furthermore, they increase bandwidth and can be harmful
445  for privacy and security. It has been possible to disable BIP 61
446  messages since v0.17 with the `-enablebip61=0` option. BIP 61 messages
447  will be disabled by default in a future version, before being removed
448  entirely.
449
450Low-level changes
451=================
452
453This section describes RPC changes mainly useful for testing, mostly not
454relevant in production. The changes are mentioned for completeness.
455
456RPC
457---
458
459- The `submitblock` RPC previously returned the reason a rejected block
460  was invalid the first time it processed that block, but returned a
461  generic "duplicate" rejection message on subsequent occasions it
462  processed the same block.  It now always returns the fundamental
463  reason for rejecting an invalid block and only returns "duplicate" for
464  valid blocks it has already accepted.
465
466- A new `submitheader` RPC allows submitting block headers independently
467  from their block.  This is likely only useful for testing.
468
469- The `signrawtransactionwithkey` and `signrawtransactionwithwallet`
470  RPCs have been modified so that they also optionally accept a
471  `witnessScript`, the witness script in the case of a P2WSH or
472  P2SH-P2WSH output. This is compatible with the change to
473  `listunspent`.
474
475- For the `walletprocesspsbt` and `walletcreatefundedpsbt` RPCs, if the
476  `bip32derivs` parameter is set to true but the key metadata for a
477  public key has not been updated yet, then that key will have a
478  derivation path as if it were just an independent key (i.e. no
479  derivation path and its master fingerprint is itself).
480
481Configuration
482-------------
483
484- The `-usehd` configuration option was removed in version 0.16. From
485  that version onwards, all new wallets created are hierarchical
486  deterministic wallets. This release makes specifying `-usehd` an
487  invalid configuration option.
488
489Network
490-------
491
492- This release allows peers that your node automatically disconnected
493  for misbehavior (e.g. sending invalid data) to reconnect to your node
494  if you have unused incoming connection slots.  If your slots fill up,
495  a misbehaving node will be disconnected to make room for nodes without
496  a history of problems (unless the misbehaving node helps your node in
497  some other way, such as by connecting to a part of the Internet from
498  which you don't have many other peers).  Previously, Bitcoin Core
499  banned the IP addresses of misbehaving peers for a period of time
500  (default of 1 day); this was easily circumvented by attackers with