release-notes-0.15.0.md raw

Bitcoin Core version 0.15.0 is now available from:

<https://bitcoin.org/bin/bitcoin-core-0.15.0/>

This is a new major version release, including new features, various bugfixes 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).

The first time you run version 0.15.0, your chainstate database will be converted to a new format, which will take anywhere from a few minutes to half an hour, depending on the speed of your machine.

The file format of fee_estimates.dat changed in version 0.15.0. Hence, a downgrade from version 0.15.0 or upgrade to version 0.15.0 will cause all fee estimates to be discarded.

Note that the block database format also changed in version 0.8.0 and there is no automatic upgrade code from before version 0.8 to version 0.15.0. Upgrading directly from 0.7.x and earlier without redownloading the blockchain is not supported. However, as usual, old wallet versions are still supported.

Downgrading warning


The chainstate database for this release is not compatible with previous releases, so if you run 0.15 and then decide to switch back to any older version, you will need to run the old release with the -reindex-chainstate option to rebuild the chainstate data structures in the old format.

If your node has pruning enabled, this will entail re-downloading and processing the entire blockchain.

Compatibility ==============

Bitcoin Core is extensively tested on multiple operating systems using the Linux kernel, macOS 10.8+, and Windows Vista and later. Windows XP is not supported.

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

Notes for 0.15.0 ================

Current SegWit support


Version 0.15.0 supports adding a segregated witness address via the addwitnessaddress RPC, but please note that this is a testing/expert RPC, which does not guarantee recovery from backup. Only use this RPC if you know what you are doing. More complete wallet support for segregated witness is coming in a next version.

Rescanning with encrypted wallets


As in previous versions, when using an encrypted HD wallet, the keypool cannot be topped up without unlocking the wallet. This means that currently, in order to recover from a backup of an encrypted HD wallet, the user must unlock the wallet with a really long timeout and manually trigger a rescan, otherwise they risk missing some keys when auto-topup cannot run. Unfortunately there is no rescan RPC in this version, that will be included in a future version, so for now a rescan can be triggered using one of the import* commands, using a dummy address generated by another (trusted) wallet.

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

Performance Improvements


Version 0.15 contains a number of significant performance improvements, which make Initial Block Download, startup, transaction and block validation much faster:

from a per-transaction model to a per-output model (See PR 10195). Advantages of this model are that it: - avoids the CPU overhead of deserializing and serializing the unused outputs; - has more predictable memory usage; - uses simpler code; - is adaptable to various future cache flushing strategies.

As a result, validating the blockchain during Initial Block Download (IBD) and reindex is ~30-40% faster, uses 10-20% less memory, and flushes to disk far less frequently. The only downside is that the on-disk database is 15% larger. During the conversion from the previous format a few extra gigabytes may be used.

As a result, only half of the available memory was actually used as cache, and the other half was reserved to accommodate flushing. This is no longer the case (See PR 10148), and the entirety of the available cache (see -dbcache) is now actually used as cache. This reduces the flushing frequency by a factor 2 or more.

transaction is accepted to the mempool. Version 0.15 extends this to cache the entire script validity (See PR 10192). This means that if a transaction in a block has already been accepted to the mempool, the scriptSig does not need to be re-evaluated. Empirical tests show that this results in new block validation being 40-50% faster.

on architectures supporting SSE 4.2. As a result, synchronization and block validation are now faster.

50% faster on supported hardware, which results in around 5% faster IBD and block validation. In version 0.15, SHA256 hardware optimization is disabled in release builds by default, but can be enabled by using --enable-experimental-asm when building.

Fee Estimation Improvements


Fee estimation has been significantly improved in version 0.15, with more accurate fee estimates used by the wallet and a wider range of options for advanced users of the estimatesmartfee and estimaterawfee RPCs (See PR 10199).

Changes to internal logic and wallet behavior

Changes to fee estimate RPCs

- The nblocks argument has been renamed to conf_target (to be consistent with other RPC methods). - An estimate_mode argument has been added. This argument takes one of the following strings: CONSERVATIVE, ECONOMICAL or UNSET (which defaults to CONSERVATIVE). - The RPC return object now contains an errors member, which returns errors encountered during processing. - If Bitcoin Core has not been running for long enough and has not seen enough blocks or transactions to produce an accurate fee estimation, an error will be returned (previously a value of -1 was used to indicate an error, which could be confused for a feerate).

Multi-wallet support

Bitcoin Core now supports loading multiple, separate wallets (See PR 8694, PR 10849). The wallets are completely separated, with individual balances, keys and received transactions.

Multi-wallet is enabled by using more than one -wallet argument when starting Bitcoin, either on the command line or in the Bitcoin config file.

In Bitcoin-Qt, only the first wallet will be displayed and accessible for creating and signing transactions. GUI selectable multiple wallets will be supported in a future version. However, even in 0.15 other loaded wallets will remain synchronized to the node's current tip in the background. This can be useful if running a pruned node, since loading a wallet where the most recent sync is beyond the pruned height results in having to download and revalidate the whole blockchain. Continuing to synchronize all wallets in the background avoids this problem.

Bitcoin Core 0.15.0 contains the following changes to the RPC interface and bitcoin-cli for multi-wallet:

Note that while multi-wallet is now fully supported, the RPC multi-wallet interface should be considered unstable for version 0.15.0, and there may backwards-incompatible changes in future versions.

Replace-by-fee control in the GUI


Bitcoin Core has supported creating opt-in replace-by-fee (RBF) transactions since version 0.12.0, and since version 0.14.0 has included a bumpfee RPC method to replace unconfirmed opt-in RBF transactions with a new transaction that pays a higher fee.

In version 0.15, creating an opt-in RBF transaction and replacing the unconfirmed transaction with a higher-fee transaction are both supported in the GUI (See PR 9592).

Removal of Coin Age Priority


In previous versions of Bitcoin Core, a portion of each block could be reserved for transactions based on the age and value of UTXOs they spent. This concept (Coin Age Priority) is a policy choice by miners, and there are no consensus rules around the inclusion of Coin Age Priority transactions in blocks. In practice, only a few miners continue to use Coin Age Priority for transaction selection in blocks. Bitcoin Core 0.15 removes all remaining support for Coin Age Priority (See PR 9602). This has the following implications:

Mempool Persistence Across Restarts


Version 0.14 introduced mempool persistence across restarts (the mempool is saved to a mempool.dat file in the data directory prior to shutdown and restores the mempool when the node is restarted). Version 0.15 allows this feature to be switched on or off using the -persistmempool command-line option (See PR 9966). By default, the option is set to true, and the mempool is saved on shutdown and reloaded on startup. If set to false, the mempool.dat file will not be loaded on startup or saved on shutdown.

New RPC methods


Version 0.15 introduces several new RPC methods:

in the chain (See PR 9733).

of these release notes for full details (See Multi-wallet support).

Low-level RPC changes


the wallet that they're intended for. See Multi-wallet support for full details.

versions of unspent outputs (See Performance improvements). This means that: - The gettxout RPC no longer has a version field in the response. - The gettxoutsetinfo RPC reports hash_serialized_2 instead of hash_serialized, which does not commit to the transaction versions of unspent outputs, but does commit to the height and coinbase information. - The getutxos REST path no longer reports the txvers field in JSON format, and always reports 0 for transaction versions in the binary format

bytes_serialized. The first is a more accurate estimate of actual disk usage, but is not deterministic. The second is unrelated to disk usage, but is a database-independent metric of UTXO set size: it counts every UTXO entry as 50 + the length of its scriptPubKey (See PR 10426).

containing one or more of the following members: - minimumAmount - a number specifying the minimum value of each UTXO - maximumAmount - a number specifying the maximum value of each UTXO - maximumCount - a number specifying the minimum number of UTXOs - minimumSumAmount - a number specifying the minimum sum value of all UTXOs

used to return no value, even if successful (See PR 9740).

(Clients should, however, use positional arguments for submitblock in order to be compatible with BIP 22.)

- getblock now returns RPCMISCERROR if the block can't be found on disk (for example if the block has been pruned). Previously returned RPCINTERNALERROR. - pruneblockchain now returns RPCMISCERROR if the blocks cannot be pruned because the node is not in pruned mode. Previously returned RPCMETHODNOT_FOUND. - pruneblockchain now returns RPCINVALIDPARAMETER if the blocks cannot be pruned because the supplied timestamp is too late. Previously returned RPCINTERNALERROR. - pruneblockchain now returns RPCMISCERROR if the blocks cannot be pruned because the blockchain is too short. Previously returned RPCINTERNALERROR. - setban now returns RPCCLIENTINVALIDIPOR_SUBNET if the supplied IP address or subnet is invalid. Previously returned RPCCLIENTNODEALREADYADDED. - setban now returns RPCCLIENTINVALIDIPOR_SUBNET if the user tries to unban a node that has not previously been banned. Previously returned RPCMISCERROR. - removeprunedfunds now returns RPCWALLETERROR if bitcoind is unable to remove the transaction. Previously returned RPCINTERNALERROR. - removeprunedfunds now returns RPCINVALIDPARAMETER if the transaction does not exist in the wallet. Previously returned RPCINTERNALERROR. - fundrawtransaction now returns RPCINVALIDADDRESSORKEY if an invalid change address is provided. Previously returned RPCINVALIDPARAMETER. - fundrawtransaction now returns RPCWALLETERROR if bitcoind is unable to create the transaction. The error message provides further details. Previously returned RPCINTERNALERROR. - bumpfee now returns RPCINVALIDPARAMETER if the provided transaction has descendants in the wallet. Previously returned RPCMISCERROR. - bumpfee now returns RPCINVALIDPARAMETER if the provided transaction has descendants in the mempool. Previously returned RPCMISCERROR. - bumpfee now returns RPCWALLETERROR if the provided transaction has has been mined or conflicts with a mined transaction. Previously returned RPCINVALIDADDRESSORKEY. - bumpfee now returns RPCWALLETERROR if the provided transaction is not BIP 125 replaceable. Previously returned RPCINVALIDADDRESSORKEY. - bumpfee now returns RPCWALLETERROR if the provided transaction has already been bumped by a different transaction. Previously returned RPCINVALIDREQUEST. - bumpfee now returns RPCWALLETERROR if the provided transaction contains inputs which don't belong to this wallet. Previously returned RPCINVALIDADDRESSORKEY. - bumpfee now returns RPCWALLETERROR if the provided transaction has multiple change outputs. Previously returned RPCMISCERROR. - bumpfee now returns RPCWALLETERROR if the provided transaction has no change output. Previously returned RPCMISCERROR. - bumpfee now returns RPCWALLETERROR if the fee is too high. Previously returned RPCMISCERROR. - bumpfee now returns RPCWALLETERROR if the fee is too low. Previously returned RPCMISCERROR. - bumpfee now returns RPCWALLETERROR if the change output is too small to bump the fee. Previously returned RPCMISCERROR.

0.15.0 Change log =================

RPC and other APIs

Block and transaction handling

P2P protocol and network code

Validation

Build system

GUI

Wallet

Tests and QA

Miscellaneous

Credits =======

Thanks to everyone who directly contributed to this release:

As well as everyone that helped translating on Transifex.