release-notes-0.19.0.1.md raw

Bitcoin Core version 0.19.0.1 is now available from:

<https://bitcoincore.org/bin/bitcoin-core-0.19.0.1/>

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 for older versions), 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 might take some time if the datadir 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.10+, and Windows 7 and newer. It is not recommended to use Bitcoin Core on unsupported systems.

Bitcoin Core should also work on most other Unix-like systems but is not as frequently tested on them.

From 0.17.0 onwards, macOS <10.10 is no longer supported. 0.17.0 is built using Qt 5.9.x, which doesn't support versions of macOS older than 10.10. Additionally, Bitcoin Core does not yet change appearance when macOS "dark mode" is activated.

Users running macOS Catalina may need to "right-click" and then choose "Open" to open the Bitcoin Core .dmg. This is due to new signing requirements imposed by Apple, which the Bitcoin Core project does not yet adhere too.

Notable changes ===============

New user documentation

suggests configuration tweaks for running Bitcoin Core on systems with limited memory. (#16339)

New RPCs

untrusted_pending and immature). Please refer to the RPC help of getbalances for details. The new RPC is intended to replace getbalance, getunconfirmedbalance, and the balance fields in getwalletinfo. These old calls and fields may be removed in a future version. (#15930, #16239)

features specific to that existing wallet, such as the new avoid_reuse feature documented elsewhere in these release notes. (#13756)

RPC is only enabled if block filters have been created using the -blockfilterindex configuration option. (#14121)

New settings

the entire blockchain. Filters will be created in the background and currently use about 4 GiB of space. Note: this version of Bitcoin Core does not serve block filters over the P2P network, although the local user may obtain block filters using the getblockfilter RPC. (#14121)

Updated settings

provide peers connecting using the indicated interfaces or IP addresses. If no permissions are specified with an address or CIDR network, the implicit default permissions are the same as previous releases. See the bitcoind -help output for these two options for details about the available permissions. (#16248)

without using any more real memory. Recent changes reduced the memory use by about 9% and made chainstate accounting more accurate (it was underestimating the use of memory before). For example, if you set a value of "450" before, you may now set a value of "500" to use about the same real amount of memory. (#16957)

Updated RPCs

Note: some low-level RPC changes mainly useful for testing are described in the Low-level Changes section below.

well-specified and would lead to RPC errors even when the wallet's coin selection succeeded. Users who want to influence coin selection can use the existing -spendzeroconfchange, -limitancestorcount, -limitdescendantcount and -walletrejectlongchains configuration arguments. (#15596)

createwallet, now accept an "avoid_reuse" parameter that controls whether already used addresses should be included in the operation. Additionally, sendtoaddress will avoid partial spends when avoid_reuse is enabled even if this feature is not already enabled via the -avoidpartialspends command line flag because not doing so would risk using up the "wrong" UTXO for an address reuse case. (#13756)

wallets. Affected RPCs are: getbalance, listreceivedbyaddress, listreceivedbylabel, listtransactions, listsinceblock, gettransaction, walletcreatefundedpsbt, and fundrawtransaction. (#16383)

wallet flag "avoid_reuse" is enabled. (#13756)

index, making it much faster, no longer dependent on the -txindex configuration option, and functional for all non-pruned blocks. (#14802)

out input and output scripts and keys when known. P2SH-witness inputs will be filled in from the UTXO set when a descriptor is provided that shows they're spending segwit outputs. See the RPC help text for full details. (#15427)

allowhighfees parameter to fail mempool acceptance if the transaction fee exceeds the value of the configuration option -maxtxfee. Now there is a hardcoded default maximum feerate that can be changed when calling either RPC using a maxfeerate parameter. (#15620)

getrawmempool no longer return a size field unless the configuration option -deprecatedrpc=size is used. Instead a new vsize field is returned with the transaction's virtual size (consistent with other RPCs such as getrawtransaction). (#15637)

(no scanning) or an object with information about the duration and progress of the wallet's scanning historical blocks for transactions affecting its balances. (#15730)

set to true, a new decoded field will be added to the response containing the decoded transaction. This field is equivalent to RPC decoderawtransaction, or RPC getrawtransaction when verbose is passed. (#16185, #16866, #16873)

will create the new wallet encrypted with the given passphrase. If unset (the default) or set to an empty string, no encryption will be used. (#16394)

window_final_block_height. (#16695)

transaction weight as defined in BIP141. (#16647)

containing the checksum for the unmodified descriptor provided by the user (that is, before the descriptor is normalized for the descriptor field). (#15986)

joined PSBT. Previously, inputs and outputs were added in the order PSBTs were provided. This made it easy to correlate inputs to outputs, representing a privacy leak. (#16512)

-walletrbf configuration option is set to true. (#15911)

GUI changes

during invoice generation using a GUI toggle, or the default address type may be changed with the -addresstype configuration option. (#15711, #16497)

Deprecated or removed configuration options

remains the same. This option previously allowed the user to prevent the node from accepting or relaying BIP125 transaction replacements. This is different from the remaining configuration option -walletrbf. (#16171)

Deprecated or removed RPCs

configuration parameter deprecatedrpc=totalFee is specified. This parameter will be fully removed in a subsequent release. (#15996)

Use the generatetoaddress RPC instead. (#15492)

P2P changes

by default, but can be enabled by setting the -enablebip61 command line option. BIP 61 reject messages will be removed entirely in a future version of Bitcoin Core. (#14054)

especially for nodes with spinning disks, the default value for the -peerbloomfilters configuration option has been changed to false. This prevents Bitcoin Core from sending the BIP111 NODE_BLOOM service flag, accepting BIP37 bloom filters, or serving merkle blocks or transactions matching a bloom filter. Users who still want to provide bloom filter support may either set the configuration option to true to re-enable both BIP111 and BIP37 support or enable just BIP37 support for specific peers using the updated -whitelist and -whitebind configuration options described elsewhere in these release notes. For the near future, lightweight clients using public BIP111/BIP37 nodes should still be able to connect to older versions of Bitcoin Core and nodes that have manually enabled BIP37 support, but developers of such software should consider migrating to either using specific BIP37 nodes or an alternative transaction filtering system. (#16152)

Miscellaneous CLI Changes

chain and now returns the current network name as defined in BIP70 (main, test, regtest). (#15566)

Low-level changes =================

RPC

Instead, information has been moved into the softforks object and an additional type field describes how Bitcoin Core determines whether that soft fork is active (e.g. BIP9 or BIP90). See the RPC help for details. (#16060)

and segwit (the BIP9 deployments that are currently in active state). (#16060)

debug.log. (#15483)

Tests

now requires transactions to not violate standard policy by default. This is the same default used for mainnet and makes it easier to test mainnet behavior on regtest. Note that the testnet still allows non-standard txs by default and that the policy can be locally adjusted with the -acceptnonstdtxn command line flag for both test chains. (#15891)

Configuration

network-specific section (e.g. testnet) will now produce an error preventing startup instead of just a warning unless the network is mainnet. This prevents settings intended for mainnet from being applied to testnet or regtest. (#15629)

the name of the thread that caused the log. To enable this behavior, use -logthreadnames=1. (#15849)

Network

Bitcoin Core would sequentially attempt to download the transaction from each announcing peer until the transaction is received, in the order that those peers' announcements were received. In this release, the download logic has changed to randomize the fetch order across peers and to prefer sending download requests to outbound peers over inbound peers. This fixes an issue where inbound peers could prevent a node from getting a transaction. (#14897, #15834)

the standard port 8333 even if a different port is configured for clearnet connections. This prevents leaking node identity through use of identical non-default port numbers. (#15651)

Mempool and transaction relay

if a transaction in the mempool had 25 descendants, or it and all of its descendants were over 101,000 vbytes, any newly-received transaction that was also a descendant would be ignored. Now, one extra descendant will be allowed provided it is an immediate descendant (child) and the child's size is 10,000 vbytes or less. This makes it possible for two-party contract protocols such as Lightning Network to give each participant an output they can spend immediately for Child-Pays-For-Parent (CPFP) fee bumping without allowing one malicious participant to fill the entire package and thus prevent the other participant from spending their output. (#15681)

segwit versions) are now accepted into the mempool, relayed, and mined. Attempting to spend those outputs remains forbidden by policy ("non-standard"). When this change has been widely deployed, wallets and services can accept any valid bech32 Bitcoin address without concern that transactions paying future segwit versions will become stuck in an unconfirmed state. (#15846)

sent using the legacy encoding format, enforcing the rule specified in BIP144. (#14039)

Wallet

importpubkey, importaddress, or importprivkey RPC will only fail when blocks have been pruned. Previously it would fail when -prune has been set. This change allows setting -prune to a high value (e.g. the disk size) without the calls to any of the import RPCs failing until the first block is pruned. (#15870)

BTC), the RPC commands walletcreatefundedpsbt and fundrawtransaction will now fail instead of rounding down the fee. Be aware that the feeRate argument is specified in BTC per 1,000 vbytes, not satoshi per vbyte. (#16257)

enabled, a wallet will distinguish between used and unused addresses, and default to not use the former in coin selection. When setting this flag on an existing wallet, rescanning the blockchain is required to correctly mark previously used destinations. Together with "avoid partial spends" (added in Bitcoin Core v0.17.0), this can eliminate a serious privacy issue where a malicious user can track spends by sending small payments to a previously-paid address that would then be included with unrelated inputs in future payments. (#13756)

Build system changes

includes the build systems, test framework and linters. The previously supported minimum (3.4), was EOL in March 2019. (#14954)

compatibility with Ubuntu 16.04 LTS and Debian 8 libminiupnpc-dev packages. Please note, on Debian this package is still vulnerable to CVE-2017-8798 (in jessie only) and CVE-2017-1000494 (both in jessie and in stretch). (#15993)

0.19.0 change log =================

Consensus

Policy

Block and transaction handling

P2P protocol and network code

Wallet

RPC and other APIs

GUI

Build system

Tests and QA

Miscellaneous

Documentation

Credits =======

Thanks to everyone who directly contributed to this release:

As well as everyone that helped translating on Transifex.