This guide explains Bitcoin Core 0.15.0 release in plain English. It summarises the important changes, who they affect and what should be checked before an upgrade.
TL;DR
- What it is: Bitcoin Core 0.15.0 was released on 14 September 2017 with a new per-output chainstate database, faster validation, redesigned fee estimation, multiwallet support and broad RPC changes. It also removed coin-age priority, exposed mempool persistence control and added several operational RPCs.
- Why it matters: Bitcoin Core 0.15.0 was an operationally large release despite its familiar interface. Chainstate incompatibility, estimator changes and wallet routing required rehearsed upgrade and rollback procedures, not an in-place binary swap.
- Current position: Bitcoin Core 0.15.0 was released on 14 September 2017 with a new per-output chainstate database, faster validation, redesigned fee estimation, multiwallet support and broad RPC changes.
Bitcoin Core 0.15.0 release in simple English
Bitcoin Core 0.15.0 release: Multiple wallets could be loaded, but wallet RPC calls needed the wallet-specific HTTP path or bitcoin-cli rpcwallet option.
Simple example
A node operator is checking Bitcoin Core 0.15.0 release. Automation must fail closed when a wallet is omitted rather than send from whichever wallet appears default.
Key terms in plain English
- Bitcoin Core:
- Widely used software that validates Bitcoin and can provide wallet, network and operator tools.
- RPC:
- A command that software sends to a node to request information or a local action.
- Consensus:
- The shared rules full nodes use to decide whether blocks and transactions are valid.
- Mempool:
- A node’s changing local collection of valid, unconfirmed transactions.
- UTXO:
- An unspent transaction output: a piece of bitcoin that can be used as an input to a later transaction.
Chainstate conversion
The UTXO database changed from a per-transaction to per-output model. Conversion could take minutes and increased the on-disk database while improving cache behaviour and validation performance. Older releases could not read the new chainstate. Pruned nodes downgrading with reindex-chainstate might need to download and process the whole blockchain again, so rollback capacity had to be planned before first start.
Fee estimation
The estimator gained short, medium and long horizons, conservative and economical modes, targets up to 1,008 blocks and better handling of evicted transactions. The fee-estimate file format also changed and estimates were discarded across the version boundary. Integrations needed fallback behaviour for insufficient data and should record returned errors, target, mode and mempool conditions.
Multiwallet routing
Multiple wallets could be loaded, but wallet RPC calls needed the wallet-specific HTTP path or bitcoin-cli rpcwallet option. Node-level calls remained on the ordinary endpoint and listwallets exposed loaded names. The 0.15.0 interface was explicitly described as unstable. Automation must fail closed when a wallet is omitted rather than send from whichever wallet appears default.
RBF and coin-age policy
The GUI added opt-in RBF creation and fee bumping. Separately, Core removed coin-age priority, free-transaction relay and related configuration and RPC fields. Mining template and relay clients had to stop relying on priority deltas while retaining the dummy positional argument where required for compatibility. These were policy changes, not new consensus validity rules.
Mempool and new RPCs
The persistmempool switch controlled loading and saving mempool.dat, defaulting to true. New calls included abortrescan, combinerawtransaction, estimaterawfee, getchaintxstats, listwallets and uptime. Signrawtransaction no longer served as a transaction combiner. Contract tests should cover named arguments, return shapes, errors and state changes across restart.
Wallet recovery warnings
addwitnessaddress remained an expert testing call without guaranteed backup recovery. Encrypted HD wallet recovery could miss keys unless the wallet stayed unlocked long enough for keypool top-up and a rescan was triggered through the documented workaround. Seed ownership alone did not prove that every experimental derivation and imported script would be rediscovered.
How specialists test it
Node operators test the release on a representative non-production system. They check startup, normal operation, failure handling and restart before changing a live node. Connected wallets, monitoring and mining services should also be checked.
Frequently asked questions
What is the main point of Bitcoin Core 0.15.0 release?
Bitcoin Core 0.15.0 release: Multiple wallets could be loaded, but wallet RPC calls needed the wallet-specific HTTP path or bitcoin-cli rpcwallet option.
For Bitcoin Core 0.15.0 release, what should a beginner know about chainstate conversion?
The UTXO database changed from a per-transaction to per-output model.
For Bitcoin Core 0.15.0 release, what should a beginner know about fee estimation?
The estimator gained short, medium and long horizons, conservative and economical modes, targets up to 1,008 blocks and better handling of evicted transactions.
For Bitcoin Core 0.15.0 release, what should a beginner know about multiwallet routing?
Multiple wallets could be loaded, but wallet RPC calls needed the wallet-specific HTTP path or bitcoin-cli rpcwallet option.
Conclusion
Bitcoin Core 0.15.0 was an operationally large release despite its familiar interface. Chainstate incompatibility, estimator changes and wallet routing required rehearsed upgrade and rollback procedures, not an in-place binary swap.
Primary sources
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
Join the ASIC Mining Discussion
Members can read and join the discussion
Log in to read comments from other miners. Create a free account if you would like to ask a question or share your experience.
Membership helps us protect the discussion from spam and keep answers useful.