Antminer X9
Monero ASIC Miner
1000KH
HASHRATE
2.47W/KH
EFFICIENCY
2470W
POWER
£857.29
EST. MONTHLY
206
DAYS
EST. ROI
This guide explains Bitcoin Core 0.14.0 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.14.0 was released on 8 March 2017 with major validation and network performance work, assumed-valid blocks, mempool persistence, manual pruning, RBF fee bumping, improved fee estimation and RPC changes. It is unsupported historical software today.
- Why it matters: Bitcoin Core 0.14.0 materially changed validation, networking, mempool and wallet operations. A safe historical rollout required exact settings, peak-resource evidence and recovery plans for both wallet state and deliberately removed data.
- Current position: Bitcoin Core 0.14.0 was released on 8 March 2017 with major validation and network performance work, assumed-valid blocks, mempool persistence, manual pruning, RBF fee bumping, improved fee estimation and RPC changes.
Bitcoin Core 0.14.0 in simple English
Bitcoin Core 0.14.0: A cuckoo signature cache, earlier compact-block relay, concurrent P2P processing and UTXO-cache use of otherwise idle mempool memory reduced sync and propagation time.
Simple example
A node operator is checking Bitcoin Core 0.14.0. Operators could disable the shipped default with assumevalid zero and benchmark the full validation path.
Key terms in plain English
- BIP:
- Bitcoin Improvement Proposal: a document describing a proposed rule, standard or process. Its status must be checked separately.
- 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.
- 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.
Performance architecture
A cuckoo signature cache, earlier compact-block relay, concurrent P2P processing and UTXO-cache use of otherwise idle mempool memory reduced sync and propagation time. Faster average operation can raise peak memory and concurrency. Operators needed CPU, RSS, disk and peer-load measurements together.
assumevalid
The new option allowed skipping historical script checks below a known block on a sufficiently-worked chain while retaining header, proof-of-work and UTXO processing. It did not force a chain like old checkpoints. Operators could disable the shipped default with assumevalid zero and benchmark the full validation path.
Mempool persistence
Core saved mempool transactions and prioritisation state to mempool.dat before shutdown and reloaded valid entries at startup. The file remained local policy state subject to chain and mempool checks. Shutdown time, stale entries and corrupt-file recovery required explicit testing.
Manual pruning
With prune set to one, pruneblockchain could remove block files up to a height or timestamp under safety constraints. That offered operator control but did not make deleted history recoverable. Rescans, indexes, serving and rollback needed a separate archival or redownload plan.
Wallet and fee changes
bumpfee could replace opt-in RBF transactions, while fundrawtransaction began reserving change keys by default to avoid reuse. The debug console hid sensitive parameters in history. Wallet tests needed fee-bump, change, backup and RPC-log cases rather than assuming security from UI redaction.
RPC migration
getinfo was deprecated and its fields moved to specialised network, blockchain and wallet calls. Named arguments and JSON error handling also evolved. Monitoring and pool integrations needed schema-aware updates with missing-field and partial-service tests.
Upgrade and rollback
Verify artefacts, stop cleanly, back up wallets and record pruning, indexes, mempool and assumevalid settings. Compare sync, relay, fee estimation and templates on primary and failover. Rollback planning must account for wallet changes and removed block data rather than replace only the executable.
Frequently asked questions
What is the main point of Bitcoin Core 0.14.0?
Bitcoin Core 0.14.0: A cuckoo signature cache, earlier compact-block relay, concurrent P2P processing and UTXO-cache use of otherwise idle mempool memory reduced sync and propagation time.
For Bitcoin Core 0.14.0, what should a beginner know about performance architecture?
A cuckoo signature cache, earlier compact-block relay, concurrent P2P processing and UTXO-cache use of otherwise idle mempool memory reduced sync and propagation time.
For Bitcoin Core 0.14.0, what should a beginner know about assumevalid?
The new option allowed skipping historical script checks below a known block on a sufficiently-worked chain while retaining header, proof-of-work and UTXO processing.
For Bitcoin Core 0.14.0, what should a beginner know about mempool persistence?
Core saved mempool transactions and prioritisation state to mempool.dat before shutdown and reloaded valid entries at startup.
Conclusion
Bitcoin Core 0.14.0 materially changed validation, networking, mempool and wallet operations. A safe historical rollout required exact settings, peak-resource evidence and recovery plans for both wallet state and deliberately removed data.
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.