Antminer X9
Monero ASIC Miner
1000KH
HASHRATE
2.47W/KH
EFFICIENCY
2470W
POWER
£851.82
EST. MONTHLY
207
DAYS
EST. ROI
This guide explains Bitcoin Core 0.13.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.13.0 was released on 23 August 2016 with compact block relay, BIP 32 key generation for newly created wallets, SegWit preparation for testnet, ancestor-aware mining selection, reindex-chainstate and many performance and networking changes. It is unsupported historical software today.
- Why it matters: Bitcoin Core 0.13.0 combined relay, wallet and mining changes with unfinished mainnet SegWit preparation. Its safe historical rollout required exact capability checks, fresh wallet backups and a recovery plan that respected new HD state.
- Current position: Bitcoin Core 0.13.0 was released on 23 August 2016 with compact block relay, BIP 32 key generation for newly created wallets, SegWit preparation for testnet, ancestor-aware mining selection, reindex-chainstate and many performance and networking changes.
Bitcoin Core 0.13.0 in simple English
Bitcoin Core 0.13.0: The release ended support for Windows XP, required newer compiler tooling for builds and added experimental ARM binaries.
Simple example
A node operator is checking Bitcoin Core 0.13.0. Operators needed to verify package hashes, platform compatibility and dependent libraries before replacing a working node.
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.
- Mempool:
- A node’s changing local collection of valid, unconfirmed transactions.
- Node:
- A computer running Bitcoin software that checks data and communicates with other peers.
Release and platform boundary
The release ended support for Windows XP, required newer compiler tooling for builds and added experimental ARM binaries. Operators needed to verify package hashes, platform compatibility and dependent libraries before replacing a working node. Historical binaries should now be confined to research networks.
Compact blocks
BIP 152 relay was automatically negotiated between compatible peers, sending short transaction identifiers so receivers reconstructed blocks from their mempools. This reduced bandwidth spikes and often propagation delay. Reconstruction success depended on similar transaction availability and policy, which mattered directly to miners.
New HD wallets
New wallets used BIP 32 derivation while existing wallets remained traditional. Encrypting an HD wallet created a new seed and required a new backup. HD wallets were incompatible with older Core versions, so a binary rollback could not be treated separately from wallet recovery.
SegWit preparation, not mainnet support
The code for BIPs 141, 143, 144 and 145 was present and testnet use was supported, but 0.13.0 had no mainnet activation parameters. It would not signal, fully validate or mine mainnet SegWit after later activation. Marketing it as a SegWit-ready production endpoint would have been misleading.
Ancestor-aware block selection
Mining selection began considering transaction feerate with unconfirmed ancestors, allowing a high-fee child to make a low-fee parent package attractive. Blockmaxweight was introduced while blockmaxsize remained with performance caveats. Pools needed template comparison and package-level fee tests.
Reindex and internal mining changes
reindex-chainstate allowed validation reconstruction without rebuilding the block index when block files were trusted. The internal CPU miner and setgenerate were removed, while test-only generation paths remained. Runbooks and test harnesses had to change rather than silently calling removed interfaces.
Upgrade and rollback rehearsal
Stop cleanly, verify the binary, copy the wallet through a supported method and record chainstate and index settings. Test compact relay, template construction, wallet backup and failover. Rollback must account for HD-wallet incompatibility and any newly created keys, not simply restore the old executable.
Frequently asked questions
What is the main point of Bitcoin Core 0.13.0?
Bitcoin Core 0.13.0: The release ended support for Windows XP, required newer compiler tooling for builds and added experimental ARM binaries.
For Bitcoin Core 0.13.0, what should a beginner know about release and platform boundary?
The release ended support for Windows XP, required newer compiler tooling for builds and added experimental ARM binaries.
For Bitcoin Core 0.13.0, what should a beginner know about compact blocks?
BIP 152 relay was automatically negotiated between compatible peers, sending short transaction identifiers so receivers reconstructed blocks from their mempools.
For Bitcoin Core 0.13.0, what should a beginner know about new HD wallets?
New wallets used BIP 32 derivation while existing wallets remained traditional. Encrypting an HD wallet created a new seed and required a new backup.
Conclusion
Bitcoin Core 0.13.0 combined relay, wallet and mining changes with unfinished mainnet SegWit preparation. Its safe historical rollout required exact capability checks, fresh wallet backups and a recovery plan that respected new HD state.
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.