Now that 0.15 branch has been split off, master is 0.15.99 (pre-0.16).
Also clean out release notes.
Tree-SHA512: 160f712fae7bfc51e49e36a27ab01f5c243b79a19a70312df95f9bc5cb8067c70aa88911f741fd1625bee549a70655eaea24d98f6049d98c3c14ee1b3143f4cb
(note: this is a temporary file, to be added-to by anybody, and moved to
(note: this is a temporary file, to be added-to by anybody, and moved to
release-notes at release time)
release-notes at release time)
Bitcoin Core version *0.15.0* is now available from:
Bitcoin Core version *version* is now available from:
<https://bitcoin.org/bin/bitcoin-core-0.15.0/>
<https://bitcoin.org/bin/bitcoin-core-*version*/>
This is a new major version release, including new features, various bugfixes
This is a new major version release, including new features, various bugfixes
and performance improvements, as well as updated translations.
and performance improvements, as well as updated translations.
@ -56,332 +56,10 @@ frequently tested on them.
Notable changes
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:
- The chainstate database (which is used for tracking UTXOs) has been changed
from a per-transaction model to a per-output model (See [PR 10195](https://github.com/bitcoin/bitcoin/pull/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.
- Earlier versions experienced a spike in memory usage while flushing UTXO updates to disk.
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](https://github.com/bitcoin/bitcoin/pull/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.
- In previous versions, signature validation for transactions has been cached when the
transaction is accepted to the mempool. Version 0.15 extends this to cache the entire script
validity (See [PR 10192](https://github.com/bitcoin/bitcoin/pull/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.
- LevelDB has been upgraded to version 1.20 (See [PR 10544](https://github.com/bitcoin/bitcoin/pull/10544)). This version contains hardware acceleration for CRC
on architectures supporting SSE 4.2. As a result, synchronization and block validation are now faster.
- SHA256 hashing has been optimized for architectures supporting SSE 4 (See [PR 10182](https://github.com/bitcoin/bitcoin/pull/10182)). SHA256 is around
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.
- Refill of the keypool no longer flushes the wallet between each key which resulted in a ~20x speedup in creating a new wallet. Part of this speedup was used to increase the default keypool to 1000 keys to make recovery more robust. (See [PR 10831](https://github.com/bitcoin/bitcoin/pull/10831)).
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](https://github.com/bitcoin/bitcoin/pull/10199)).
### Changes to internal logic and wallet behavior
- Internally, estimates are now tracked on 3 different time horizons. This allows for longer targets and means estimates adjust more quickly to changes in conditions.
- Estimates can now be *conservative* or *economical*. *Conservative* estimates use longer time horizons to produce an estimate which is less susceptible to rapid changes in fee conditions. *Economical* estimates use shorter time horizons and will be more affected by short-term changes in fee conditions. Economical estimates may be considerably lower during periods of low transaction activity (for example over weekends), but may result in transactions being unconfirmed if prevailing fees increase rapidly.
- By default, the wallet will use conservative fee estimates to increase the reliability of transactions being confirmed within the desired target. For transactions that are marked as replaceable, the wallet will use an economical estimate by default, since the fee can be 'bumped' if the fee conditions change rapidly (See [PR 10589](https://github.com/bitcoin/bitcoin/pull/10589)).
- Estimates can now be made for confirmation targets up to 1008 blocks (one week).
- More data on historical fee rates is stored, leading to more precise fee estimates.
- Transactions which leave the mempool due to eviction or other non-confirmed reasons are now taken into account by the fee estimation logic, leading to more accurate fee estimates.
- The fee estimation logic will make sure enough data has been gathered to return a meaningful estimate. If there is insufficient data, a fallback default fee is used.
### Changes to fee estimate RPCs
- The `estimatefee` RPC is now deprecated in favor of using only `estimatesmartfee` (which is the implementation used by the GUI)
- The `estimatesmartfee` RPC interface has been changed (See [PR 10707](https://github.com/bitcoin/bitcoin/pull/10707)):
- 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).
- A new `estimaterawfee` RPC is added to provide raw fee data. External clients can query and use this data in their own fee estimation logic.
Multi-wallet support
--------------------
Bitcoin Core now supports loading multiple, separate wallets (See [PR 8694](https://github.com/bitcoin/bitcoin/pull/8694), [PR 10849](https://github.com/bitcoin/bitcoin/pull/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 continue to 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:
* When running Bitcoin Core with a single wallet, there are **no** changes to the RPC interface or `bitcoin-cli`. All RPC calls and `bitcoin-cli` commands continue to work as before.
* When running Bitcoin Core with multi-wallet, all *node-level* RPC methods continue to work as before. HTTP RPC requests should be send to the normal `<RPC IP address>:<RPC port>/` endpoint, and `bitcoin-cli` commands should be run as before. A *node-level* RPC method is any method which does not require access to the wallet.
* When running Bitcoin Core with multi-wallet, *wallet-level* RPC methods must specify the wallet for which they're intended in every request. HTTP RPC requests should be send to the `<RPC IP address>:<RPC port>/wallet/<wallet name>/` endpoint, for example `127.0.0.1:8332/wallet/wallet1.dat/`. `bitcoin-cli` commands should be run with a `-rpcwallet` option, for example `bitcoin-cli -rpcwallet=wallet1.dat getbalance`.
* A new *node-level*`listwallets` RPC method is added to display which wallets are currently loaded. The names returned by this method are the same as those used in the HTTP endpoint and for the `rpcwallet` argument.
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](https://github.com/bitcoin/bitcoin/pull/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](https://github.com/bitcoin/bitcoin/pull/9602)). This has the following implications:
- The concept of *free transactions* has been removed. High Coin Age Priority transactions would previously be allowed to be relayed even if they didn't attach a miner fee. This is no longer possible since there is no concept of Coin Age Priority. The `-limitfreerelay` and `-relaypriority` options which controlled relay of free transactions have therefore been removed.
- The `-sendfreetransactions` option has been removed, since almost all miners do not include transactions which do not attach a transaction fee.
- The `-blockprioritysize` option has been removed.
- The `estimatepriority` and `estimatesmartpriority` RPCs have been removed.
- The `getmempoolancestors`, `getmempooldescendants`, `getmempooolentry` and `getrawmempool` RPCs no longer return `startingpriority` and `currentpriority`.
- The `prioritisetransaction` RPC no longer takes a `priority_delta` argument, which is replaced by a `dummy` argument for backwards compatibility with clients using positional arguments. The RPC is still used to change the apparent fee-rate of the transaction by using the `fee_delta` argument.
- `-minrelaytxfee` can now be set to 0. If `minrelaytxfee` is set, then fees smaller than `minrelaytxfee` (per kB) are rejected from relaying, mining and transaction creation. This defaults to 1000 satoshi/kB.
- The `-printpriority` option has been updated to only output the fee rate and hash of transactions included in a block by the mining code.
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](https://github.com/bitcoin/bitcoin/pull/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:
- `abortrescan` stops current wallet rescan, e.g. when triggered by an `importprivkey` call (See [PR 10208](https://github.com/bitcoin/bitcoin/pull/10208)).
- `combinerawtransaction` accepts a JSON array of raw transactions and combines them into a single raw transaction (See [PR 10571](https://github.com/bitcoin/bitcoin/pull/10571)).
- `estimaterawfee` returns raw fee data so that customized logic can be implemented to analyze the data and calculate estimates. See [Fee Estimation Improvements](#fee-estimation-improvements) for full details on changes to the fee estimation logic and interface.
- `getchaintxstats` returns statistics about the total number and rate of transactions
in the chain (See [PR 9733](https://github.com/bitcoin/bitcoin/pull/9733)).
- `listwallets` lists wallets which are currently loaded. See the *Multi-wallet* section
of these release notes for full details (See [Multi-wallet support](#multi-wallet-support)).
- `uptime` returns the total runtime of the `bitcoind` server since its last start (See [PR 10400](https://github.com/bitcoin/bitcoin/pull/10400)).
Low-level RPC changes
---------------------
- When using Bitcoin Core in multi-wallet mode, RPC requests for wallet methods must specify
the wallet that they're intended for. See [Multi-wallet support](#multi-wallet-support) for full details.
- The new database model no longer stores information about transaction
versions of unspent outputs (See [Performance improvements](#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
- The `estimatefee` RPC is deprecated. Clients should switch to using the `estimatesmartfee` RPC, which returns better fee estimates. See [Fee Estimation Improvements](#fee-estimation-improvements) for full details on changes to the fee estimation logic and interface.
- The `gettxoutsetinfo` response now contains `disk_size` and `bogosize` instead of
`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](https://github.com/bitcoin/bitcoin/pull/10426)).
- `signrawtransaction` can no longer be used to combine multiple transactions into a single transaction. Instead, use the new `combinerawtransaction` RPC (See [PR 10571](https://github.com/bitcoin/bitcoin/pull/10571)).
- `fundrawtransaction` no longer accepts a `reserveChangeKey` option. This option used to allow RPC users to fund a raw transaction using an key from the keypool for the change address without removing it from the available keys in the keypool. The key could then be re-used for a `getnewaddress` call, which could potentially result in confusing or dangerous behaviour (See [PR 10784](https://github.com/bitcoin/bitcoin/pull/10784)).
- `estimatepriority` and `estimatesmartpriority` have been removed. See [Removal of Coin Age Priority](#removal-of-coin-age-priority).
- The `listunspent` RPC now takes a `query_options` argument (see [PR 8952](https://github.com/bitcoin/bitcoin/pull/8952)), which is a JSON object
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
- The `getmempoolancestors`, `getmempooldescendants`, `getmempooolentry` and `getrawmempool` RPCs no longer return `startingpriority` and `currentpriority`. See [Removal of Coin Age Priority](#removal-of-coin-age-priority).
- The `dumpwallet` RPC now returns the full absolute path to the dumped wallet. (it
used to return no value, even if successful (See [PR 9740](https://github.com/bitcoin/bitcoin/pull/9740)).
- In the `getpeerinfo` RPC, the return object for each peer now returns an `addrbind` member, which contains the ip address and port of the connection to the peer. This is in addition to the `addrlocal` member which contains the ip address and port of the local node as reported by the peer (See [PR 10478](https://github.com/bitcoin/bitcoin/pull/10478)).
- The `disconnectnode` RPC can now disconnect a node specified by node ID (as well as by IP address/port). To disconnect a node based on node ID, call the RPC with the new `nodeid` argument (See [PR 10143](https://github.com/bitcoin/bitcoin/pull/10143)).
- The second argument in `prioritisetransaction` has been renamed from `priority_delta` to `dummy` since Bitcoin Core no longer has a concept of coin age priority. The `dummy` argument has no functional effect, but is retained for positional argument compatibility. See [Removal of Coin Age Priority](#removal-of-coin-age-priority).
- The `resendwallettransactions` RPC throws an error if the `-walletbroadcast` option is set to false (See [PR 10995](https://github.com/bitcoin/bitcoin/pull/10995)).
- The second argument in the `submitblock` RPC argument has been renamed from `parameters` to `dummy`. This argument never had any effect, and the renaming is simply to communicate this fact to the user (See [PR 10191](https://github.com/bitcoin/bitcoin/pull/10191))
(Clients should, however, use positional arguments for `submitblock` in order to be compatible with BIP 22.)
- The `verbose` argument of `getblock` has been renamed to `verbosity` and now takes an integer from 0-2. Verbose level 0 is equivalent to `verbose=false`. Verbose level 1 is equivalent to `verbose=true`. Verbose level 2 will give the full transaction details of each transaction in the output as given by `getrawtransaction`. The old behavior of using the `verbose` named argument and a boolean value is still maintained for compatibility.
- Error codes have been updated to be more accurate for the following error cases (See [PR 9853](https://github.com/bitcoin/bitcoin/pull/9853)):
- `getblock` now returns RPC_MISC_ERROR if the block can't be found on disk (for
example if the block has been pruned). Previously returned RPC_INTERNAL_ERROR.
- `pruneblockchain` now returns RPC_MISC_ERROR if the blocks cannot be pruned
because the node is not in pruned mode. Previously returned RPC_METHOD_NOT_FOUND.
- `pruneblockchain` now returns RPC_INVALID_PARAMETER if the blocks cannot be pruned
because the supplied timestamp is too late. Previously returned RPC_INTERNAL_ERROR.
- `pruneblockchain` now returns RPC_MISC_ERROR if the blocks cannot be pruned
because the blockchain is too short. Previously returned RPC_INTERNAL_ERROR.
- `setban` now returns RPC_CLIENT_INVALID_IP_OR_SUBNET if the supplied IP address
or subnet is invalid. Previously returned RPC_CLIENT_NODE_ALREADY_ADDED.
- `setban` now returns RPC_CLIENT_INVALID_IP_OR_SUBNET if the user tries to unban
a node that has not previously been banned. Previously returned RPC_MISC_ERROR.
- `removeprunedfunds` now returns RPC_WALLET_ERROR if `bitcoind` is unable to remove
the transaction. Previously returned RPC_INTERNAL_ERROR.
- `removeprunedfunds` now returns RPC_INVALID_PARAMETER if the transaction does not
exist in the wallet. Previously returned RPC_INTERNAL_ERROR.
- `fundrawtransaction` now returns RPC_INVALID_ADDRESS_OR_KEY if an invalid change
address is provided. Previously returned RPC_INVALID_PARAMETER.
- `fundrawtransaction` now returns RPC_WALLET_ERROR if `bitcoind` is unable to create
the transaction. The error message provides further details. Previously returned
RPC_INTERNAL_ERROR.
- `bumpfee` now returns RPC_INVALID_PARAMETER if the provided transaction has
descendants in the wallet. Previously returned RPC_MISC_ERROR.
- `bumpfee` now returns RPC_INVALID_PARAMETER if the provided transaction has
descendants in the mempool. Previously returned RPC_MISC_ERROR.
- `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction has
has been mined or conflicts with a mined transaction. Previously returned
RPC_INVALID_ADDRESS_OR_KEY.
- `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction is not
BIP 125 replaceable. Previously returned RPC_INVALID_ADDRESS_OR_KEY.
- `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction has already
been bumped by a different transaction. Previously returned RPC_INVALID_REQUEST.
- `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction contains
inputs which don't belong to this wallet. Previously returned RPC_INVALID_ADDRESS_OR_KEY.
- `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction has multiple change
outputs. Previously returned RPC_MISC_ERROR.
- `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction has no change
output. Previously returned RPC_MISC_ERROR.
- `bumpfee` now returns RPC_WALLET_ERROR if the fee is too high. Previously returned
RPC_MISC_ERROR.
- `bumpfee` now returns RPC_WALLET_ERROR if the fee is too low. Previously returned
RPC_MISC_ERROR.
- `bumpfee` now returns RPC_WALLET_ERROR if the change output is too small to bump the
fee. Previously returned RPC_MISC_ERROR.
Credits
Credits
=======
=======
Thanks to everyone who directly contributed to this release:
Thanks to everyone who directly contributed to this release:
- ロハン ダル
- Ahmad Kazi
- aideca
- Akio Nakamura
- Alex Morcos
- Allan Doensen
- Andres G. Aragoneses
- Andrew Chow
- Awemany
- Bob McElrath
- Brian McMichael
- BtcDrak
- Charlie Lee
- Chris Gavin
- Chris Stewart
- Cory Fields
- CryptAxe
- Dag Robole
- Daniel Aleksandersen
- Daniel Cousens
- darksh1ne
- Dimitris Tsapakidis
- Eric Shaw Jr
- Evan Klitzke
- fanquake
- Felix Weis
- flack
- Greg Griffith
- Gregory Maxwell
- Gregory Sanders
- gubatron
- Ian Kelling
- Jack Grigg
- James Evans
- James Hilliard
- Jameson Lopp
- Jeremy Rubin
- Jimmy Song
- João Barbosa
- Johnathan Corgan
- John Newbery
- Jonas Schnelli
- jonnynewbs
- Jorge Timón
- Kalle Alm
- Karl-Johan Alm
- Kewde
- keystrike
- KibbledJiveElkZoo
- Kibbled Jive Elk Zoo
- kirit93
- kobake
- Kyle Honeycutt
- Lawrence Nahum
- Luke Dashjr
- Marco Falke
- Marcos Mayorga
- Marijn Stollenga
- Mario Dian
- Mark Friedenbach
- Marko Bencun
- Masahiko Hyuga
- Matt Corallo
- Matthew Zipkin
- Matthias Grundmann
- Michael Goldstein
- Michael Rotarius
- Mikerah
- Mike van Rossum
- Mitchell Cash
- NicolasDorier
- Nicolas Dorier
- Patrick Strateman
- Pavel Janík
- Pavlos Antoniou
- Pavol Rusnak
- Pedro Branco
- Peter Todd
- Pieter Wuille
- practicalswift
- René Nyffenegger
- Ricardo Velhote
- romanornr
- Russell Yanofsky
- Rusty Russell
- Ryan Havar
- shaolinfry
- Shigeya Suzuki
- Simone Madeo
- Spencer Lievens
- Steven D. Lander
- Suhas Daftuar
- Takashi Mitsuta
- Thomas Snider
- Timothy Redaelli
- tintinweb
- tnaka
- Warren Togami
- Wladimir J. van der Laan
As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/).
As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/).
Wladimir J. van der Laan
8 years ago