1Bitcoin Core version *0.15.0* is now available from:
2
3  <https://bitcoin.org/bin/bitcoin-core-0.15.0/>
4
5This is a new major version release, including new features, various bugfixes
6and performance improvements, as well as updated translations.
7
8Please report bugs using the issue tracker at GitHub:
9
10  <https://github.com/bitcoin/bitcoin/issues>
11
12To receive security and update notifications, please subscribe to:
13
14  <https://bitcoincore.org/en/list/announcements/join/>
15
16How to Upgrade
17==============
18
19If you are running an older version, shut it down. Wait until it has completely
20shut down (which might take a few minutes for older versions), then run the 
21installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
22or `bitcoind`/`bitcoin-qt` (on Linux).
23
24The first time you run version 0.15.0, your chainstate database will be converted to a
25new format, which will take anywhere from a few minutes to half an hour,
26depending on the speed of your machine.
27
28The file format of `fee_estimates.dat` changed in version 0.15.0. Hence, a
29downgrade from version 0.15.0 or upgrade to version 0.15.0 will cause all fee
30estimates to be discarded.
31
32Note that the block database format also changed in version 0.8.0 and there is no
33automatic upgrade code from before version 0.8 to version 0.15.0. Upgrading
34directly from 0.7.x and earlier without redownloading the blockchain is not supported.
35However, as usual, old wallet versions are still supported.
36
37Downgrading warning
38-------------------
39
40The chainstate database for this release is not compatible with previous
41releases, so if you run 0.15 and then decide to switch back to any
42older version, you will need to run the old release with the `-reindex-chainstate`
43option to rebuild the chainstate data structures in the old format.
44
45If your node has pruning enabled, this will entail re-downloading and
46processing the entire blockchain.
47
48Compatibility
49==============
50
51Bitcoin Core is extensively tested on multiple operating systems using
52the Linux kernel, macOS 10.8+, and Windows Vista and later. Windows XP is not supported.
53
54Bitcoin Core should also work on most other Unix-like systems but is not
55frequently tested on them.
56
57Notes for 0.15.0
58================
59
60Current SegWit support
61----------------------
62
63Version 0.15.0 supports adding a segregated witness address via the `addwitnessaddress` RPC, but
64please note that this is a testing/expert RPC, which does not guarantee recovery from backup. Only use
65this RPC if you know what you are doing. More complete wallet support for segregated witness is coming
66in a next version.
67
68Rescanning with encrypted wallets
69---------------------------------
70
71As in previous versions, when using an encrypted HD wallet, the keypool cannot be topped up without unlocking
72the wallet. This means that currently, in order to recover from a backup of an encrypted HD wallet, the user
73must unlock the wallet with a really long timeout and manually trigger a rescan, otherwise they risk missing
74some keys when auto-topup cannot run. Unfortunately there is no `rescan` RPC in this version, that will be
75included in a future version, so for now a rescan can be triggered using one of the `import*` commands, using
76a dummy address generated by another (trusted) wallet.
77
78Notable changes
79===============
80
81Performance Improvements
82------------------------
83
84Version 0.15 contains a number of significant performance improvements, which make
85Initial Block Download, startup, transaction and block validation much faster:
86
87- The chainstate database (which is used for tracking UTXOs) has been changed
88  from a per-transaction model to a per-output model (See [PR 10195](https://github.com/bitcoin/bitcoin/pull/10195)). Advantages of this model
89  are that it:
90    - avoids the CPU overhead of deserializing and serializing the unused outputs;
91    - has more predictable memory usage;
92    - uses simpler code;
93    - is adaptable to various future cache flushing strategies.
94
95  As a result, validating the blockchain during Initial Block Download (IBD) and reindex
96  is ~30-40% faster, uses 10-20% less memory, and flushes to disk far less frequently.
97  The only downside is that the on-disk database is 15% larger. During the conversion from the previous format
98  a few extra gigabytes may be used.
99- Earlier versions experienced a spike in memory usage while flushing UTXO updates to disk.
100  As a result, only half of the available memory was actually used as cache, and the other half was
101  reserved to accommodate flushing. This is no longer the case (See [PR 10148](https://github.com/bitcoin/bitcoin/pull/10148)), and the entirety of
102  the available cache (see `-dbcache`) is now actually used as cache. This reduces the flushing
103  frequency by a factor 2 or more.
104- In previous versions, signature validation for transactions has been cached when the
105  transaction is accepted to the mempool. Version 0.15 extends this to cache the entire script
106  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
107  mempool, the scriptSig does not need to be re-evaluated. Empirical tests show that
108  this results in new block validation being 40-50% faster.
109- 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
110  on architectures supporting SSE 4.2. As a result, synchronization and block validation are now faster.
111- SHA256 hashing has been optimized for architectures supporting SSE 4 (See [PR 10821](https://github.com/bitcoin/bitcoin/pull/10821)). SHA256 is around
112  50% faster on supported hardware, which results in around 5% faster IBD and block
113  validation. In version 0.15, SHA256 hardware optimization is disabled in release builds by
114  default, but can be enabled by using `--enable-experimental-asm` when building.
115- 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)).
116
117Fee Estimation Improvements
118---------------------------
119
120Fee 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)).
121
122### Changes to internal logic and wallet behavior
123
124- 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.
125- 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.
126- 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)).
127- Estimates can now be made for confirmation targets up to 1008 blocks (one week).
128- More data on historical fee rates is stored, leading to more precise fee estimates.
129- 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.
130- 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.
131
132### Changes to fee estimate RPCs
133
134- The `estimatefee` RPC is now deprecated in favor of using only `estimatesmartfee` (which is the implementation used by the GUI)
135- The `estimatesmartfee` RPC interface has been changed (See [PR 10707](https://github.com/bitcoin/bitcoin/pull/10707)):
136    - The `nblocks` argument has been renamed to `conf_target` (to be consistent with other RPC methods).
137    - An `estimate_mode` argument has been added. This argument takes one of the following strings: `CONSERVATIVE`, `ECONOMICAL` or `UNSET` (which defaults to `CONSERVATIVE`).
138    - The RPC return object now contains an `errors` member, which returns errors encountered during processing.
139    - 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).
140- 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.
141
142Multi-wallet support
143--------------------
144
145Bitcoin 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.
146
147Multi-wallet is enabled by using more than one `-wallet` argument when starting Bitcoin, either on the command line or in the Bitcoin config file.
148
149**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.
150
151Bitcoin Core 0.15.0 contains the following changes to the RPC interface and `bitcoin-cli` for multi-wallet:
152
153* 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.
154* 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.
155* 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`.
156* 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.
157
158Note 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.
159
160Replace-by-fee control in the GUI
161---------------------------------
162
163Bitcoin Core has supported creating opt-in replace-by-fee (RBF) transactions
164since version 0.12.0, and since version 0.14.0 has included a `bumpfee` RPC method to
165replace unconfirmed opt-in RBF transactions with a new transaction that pays
166a higher fee.
167
168In version 0.15, creating an opt-in RBF transaction and replacing the unconfirmed
169transaction with a higher-fee transaction are both supported in the GUI (See [PR 9592](https://github.com/bitcoin/bitcoin/pull/9592)).
170
171Removal of Coin Age Priority
172----------------------------
173
174In 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:
175
176- 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.
177- The `-sendfreetransactions` option has been removed, since almost all miners do not include transactions which do not attach a transaction fee.
178- The `-blockprioritysize` option has been removed.
179- The `estimatepriority` and `estimatesmartpriority` RPCs have been removed.
180- The `getmempoolancestors`, `getmempooldescendants`, `getmempoolentry` and `getrawmempool` RPCs no longer return `startingpriority` and `currentpriority`.
181- 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.
182- `-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.
183- The `-printpriority` option has been updated to only output the fee rate and hash of transactions included in a block by the mining code.
184
185Mempool Persistence Across Restarts
186-----------------------------------
187
188Version 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.
189
190New RPC methods
191---------------
192
193Version 0.15 introduces several new RPC methods:
194
195- `abortrescan` stops current wallet rescan, e.g. when triggered by an `importprivkey` call (See [PR 10208](https://github.com/bitcoin/bitcoin/pull/10208)).
196- `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)).
197- `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.
198- `getchaintxstats` returns statistics about the total number and rate of transactions
199  in the chain (See [PR 9733](https://github.com/bitcoin/bitcoin/pull/9733)).
200- `listwallets` lists wallets which are currently loaded. See the *Multi-wallet* section
201  of these release notes for full details (See [Multi-wallet support](#multi-wallet-support)).
202- `uptime` returns the total runtime of the `bitcoind` server since its last start (See [PR 10400](https://github.com/bitcoin/bitcoin/pull/10400)).
203
204Low-level RPC changes
205---------------------
206
207- When using Bitcoin Core in multi-wallet mode, RPC requests for wallet methods must specify
208  the wallet that they're intended for. See [Multi-wallet support](#multi-wallet-support) for full details.
209
210- The new database model no longer stores information about transaction
211  versions of unspent outputs (See [Performance improvements](#performance-improvements)). This means that:
212  - The `gettxout` RPC no longer has a `version` field in the response.
213  - The `gettxoutsetinfo` RPC reports `hash_serialized_2` instead of `hash_serialized`,
214    which does not commit to the transaction versions of unspent outputs, but does
215    commit to the height and coinbase information.
216  - The `getutxos` REST path no longer reports the `txvers` field in JSON format,
217    and always reports 0 for transaction versions in the binary format
218
219- 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.
220
221- The `gettxoutsetinfo` response now contains `disk_size` and `bogosize` instead of
222  `bytes_serialized`. The first is a more accurate estimate of actual disk usage, but
223  is not deterministic. The second is unrelated to disk usage, but is a
224  database-independent metric of UTXO set size: it counts every UTXO entry as 50 + the
225  length of its scriptPubKey (See [PR 10426](https://github.com/bitcoin/bitcoin/pull/10426)).
226
227- `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)).
228
229- `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)).
230
231- `estimatepriority` and `estimatesmartpriority` have been removed. See [Removal of Coin Age Priority](#removal-of-coin-age-priority).
232
233- The `listunspent` RPC now takes a `query_options` argument (see [PR 8952](https://github.com/bitcoin/bitcoin/pull/8952)), which is a JSON object
234  containing one or more of the following members:
235  - `minimumAmount` - a number specifying the minimum value of each UTXO
236  - `maximumAmount` - a number specifying the maximum value of each UTXO
237  - `maximumCount` - a number specifying the minimum number of UTXOs
238  - `minimumSumAmount` - a number specifying the minimum sum value of all UTXOs
239
240- The `getmempoolancestors`, `getmempooldescendants`, `getmempoolentry` and `getrawmempool` RPCs no longer return `startingpriority` and `currentpriority`. See [Removal of Coin Age Priority](#removal-of-coin-age-priority).
241
242- The `dumpwallet` RPC now returns the full absolute path to the dumped wallet. It
243  used to return no value, even if successful (See [PR 9740](https://github.com/bitcoin/bitcoin/pull/9740)).
244
245- 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)).
246
247- 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)).
248
249- 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).
250