Inside Bitcoin
Opening the selected file…
Inside Bitcoin
Opening the selected file…
The code behind the network, with room to understand it.
Release published 2026-10-28 · Snapshot fetched 2026-11-01. Latest stable release at fetch time; development branches and Git history are excluded. Only the selected code window and visible folders load here.
1Bitcoin Core version 0.13.0 is now available from:3<https://bitcoin.org/bin/bitcoin-core-0.13.0/>5This is a new major version release, including new features, various bugfixes6and performance improvements, as well as updated translations.8Please report bugs using the issue tracker at github:10<https://github.com/bitcoin/bitcoin/issues>12To receive security and update notifications, please subscribe to:14<https://bitcoincore.org/en/list/announcements/join/>16Compatibility17==============19Microsoft ended support for Windows XP on [April 8th, 2014](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support),20an OS initially released in 2001. This means that not even critical security21updates will be released anymore. Without security updates, using a bitcoin22wallet on a XP machine is irresponsible at least.24In addition to that, with 0.12.x there have been varied reports of Bitcoin Core25randomly crashing on Windows XP. It is [not clear](https://github.com/bitcoin/bitcoin/issues/7681#issuecomment-217439891)26what the source of these crashes is, but it is likely that upstream27libraries such as Qt are no longer being tested on XP.29We do not have time nor resources to provide support for an OS that is30end-of-life. From 0.13.0 on, Windows XP is no longer supported. Users are31suggested to upgrade to a newer verion of Windows, or install an alternative OS32that is supported.34No attempt is made to prevent installing or running the software on Windows XP,35you can still do so at your own risk, but do not expect it to work: do not36report issues about Windows XP to the issue tracker.38Notable changes39===============41Database cache memory increased42--------------------------------44As a result of growth of the UTXO set, performance with the prior default45database cache of 100 MiB has suffered.46For this reason the default was changed to 300 MiB in this release.48For nodes on low-memory systems, the database cache can be changed back to49100 MiB (or to another value) by either:51- Adding `dbcache=100` in bitcoin.conf52- Changing it in the GUI under `Options → Size of database cache`54Note that the database cache setting has the most performance impact55during initial sync of a node, and when catching up after downtime.58bitcoin-cli: arguments privacy59------------------------------61The RPC command line client gained a new argument, `-stdin`62to read extra arguments from standard input, one per line until EOF/Ctrl-D.63For example:65$ src/bitcoin-cli -stdin walletpassphrase66mysecretcode6712068..... press Ctrl-D here to end input69$71It is recommended to use this for sensitive information such as wallet72passphrases, as command-line arguments can usually be read from the process73table by any user on the system.76C++11 and Python 377------------------79Various code modernizations have been done. The Bitcoin Core code base has80started using C++11. This means that a C++11-capable compiler is now needed for81building. Effectively this means GCC 4.7 or higher, or Clang 3.3 or higher.83When cross-compiling for a target that doesn't have C++11 libraries, configure with84`./configure --enable-glibc-back-compat ... LDFLAGS=-static-libstdc++`.86For running the functional tests in `qa/rpc-tests`, Python3.4 or higher is now87required.90Linux ARM builds91----------------93Due to popular request, Linux ARM builds have been added to the uploaded94executables.96The following extra files can be found in the download directory or torrent:98- `bitcoin-${VERSION}-arm-linux-gnueabihf.tar.gz`: Linux binaries targeting99the 32-bit ARMv7-A architecture.100- `bitcoin-${VERSION}-aarch64-linux-gnu.tar.gz`: Linux binaries targeting101the 64-bit ARMv8-A architecture.103ARM builds are still experimental. If you have problems on a certain device or104Linux distribution combination please report them on the bug tracker, it may be105possible to resolve them. Note that the device you use must be (backward)106compatible with the architecture targeted by the binary that you use.107For example, a Raspberry Pi 2 Model B or Raspberry Pi 3 Model B (in its 32-bit108execution state) device, can run the 32-bit ARMv7-A targeted binary. However,109no model of Raspberry Pi 1 device can run either binary because they are all110ARMv6 architecture devices that are not compatible with ARMv7-A or ARMv8-A.112Note that Android is not considered ARM Linux in this context. The executables113are not expected to work out of the box on Android.116Compact Block support (BIP 152)117-------------------------------119Support for block relay using the Compact Blocks protocol has been implemented120in PR 8068.122The primary goal is reducing the bandwidth spikes at relay time, though in many123cases it also reduces propagation delay. It is automatically enabled between124compatible peers.125[BIP 152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki)127As a side-effect, ordinary non-mining nodes will download and upload blocks128faster if those blocks were produced by miners using similar transaction129filtering policies. This means that a miner who produces a block with many130transactions discouraged by your node will be relayed slower than one with131only transactions already in your memory pool. The overall effect of such132relay differences on the network may result in blocks which include widely-133discouraged transactions losing a stale block race, and therefore miners may134wish to configure their node to take common relay policies into consideration.137Hierarchical Deterministic Key Generation138-----------------------------------------139Newly created wallets will use hierarchical deterministic key generation140according to BIP32 (keypath m/0'/0'/k').141Existing wallets will still use traditional key generation.143Backups of HD wallets, regardless of when they have been created, can144therefore be used to re-generate all possible private keys, even the145ones which haven't already been generated during the time of the backup.146**Attention:** Encrypting the wallet will create a new seed which requires147a new backup!149Wallet dumps (created using the `dumpwallet` RPC) will contain the deterministic150seed. This is expected to allow future versions to import the seed and all151associated funds, but this is not yet implemented.153HD key generation for new wallets can be disabled by `-usehd=0`. Keep in154mind that this flag only has affect on newly created wallets.155You can't disable HD key generation once you have created a HD wallet.157There is no distinction between internal (change) and external keys.159HD wallets are incompatible with older versions of Bitcoin Core.161[Pull request](https://github.com/bitcoin/bitcoin/pull/8035/files), [BIP 32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)164Segregated Witness165------------------167The code preparations for Segregated Witness ("segwit"), as described in [BIP168141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki), [BIP169143](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki), [BIP170144](https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki), and [BIP171145](https://github.com/bitcoin/bips/blob/master/bip-0145.mediawiki) are172finished and included in this release. However, BIP 141 does not yet specify173activation parameters on mainnet, and so this release does not support segwit174use on mainnet. Testnet use is supported, and after BIP 141 is updated with175proposed parameters, a future release of Bitcoin Core is expected that176implements those parameters for mainnet.178Furthermore, because segwit activation is not yet specified for mainnet,179version 0.13.0 will behave similarly as other pre-segwit releases even after a180future activation of BIP 141 on the network. Upgrading from 0.13.0 will be181required in order to utilize segwit-related features on mainnet (such as signal182BIP 141 activation, mine segwit blocks, fully validate segwit blocks, relay183segwit blocks to other segwit nodes, and use segwit transactions in the184wallet, etc).187Mining transaction selection ("Child Pays For Parent")188------------------------------------------------------190The mining transaction selection algorithm has been replaced with an algorithm191that selects transactions based on their feerate inclusive of unconfirmed192ancestor transactions. This means that a low-fee transaction can become more193likely to be selected if a high-fee transaction that spends its outputs is194relayed.196With this change, the `-blockminsize` command line option has been removed.198The command line option `-blockmaxsize` remains an option to specify the199maximum number of serialized bytes in a generated block. In addition, the new200command line option `-blockmaxweight` has been added, which specifies the201maximum "block weight" of a generated block, as defined by [BIP 141 (Segregated202Witness)] (https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki).204In preparation for Segregated Witness, the mining algorithm has been modified205to optimize transaction selection for a given block weight, rather than a given206number of serialized bytes in a block. In this release, transaction selection207is unaffected by this distinction (as BIP 141 activation is not supported on208mainnet in this release, see above), but in future releases and after BIP 141209activation, these calculations would be expected to differ.211For optimal runtime performance, miners using this release should specify212`-blockmaxweight` on the command line, and not specify `-blockmaxsize`.213Additionally (or only) specifying `-blockmaxsize`, or relying on default214settings for both, may result in performance degradation, as the logic to215support `-blockmaxsize` performs additional computation to ensure that216constraint is met. (Note that for mainnet, in this release, the equivalent217parameter for `-blockmaxweight` would be four times the desired218`-blockmaxsize`. See [BIP 141]219(https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) for additional220details.)222In the future, the `-blockmaxsize` option may be removed, as block creation is223no longer optimized for this metric. Feedback is requested on whether to224deprecate or keep this command line option in future releases.227Reindexing changes228------------------230In earlier versions, reindexing did validation while reading through the block231files on disk. These two have now been split up, so that all blocks are known232before validation starts. This was necessary to make certain optimizations that233are available during normal synchronizations also available during reindexing.235The two phases are distinct in the Bitcoin-Qt GUI. During the first one,236"Reindexing blocks on disk" is shown. During the second (slower) one,237"Processing blocks on disk" is shown.239It is possible to only redo validation now, without rebuilding the block index,240using the command line option `-reindex-chainstate` (in addition to241`-reindex` which does both). This new option is useful when the blocks on disk242are assumed to be fine, but the chainstate is still corrupted. It is also243useful for benchmarks.246Removal of internal miner247--------------------------249As CPU mining has been useless for a long time, the internal miner has been250removed in this release, and replaced with a simpler implementation for the
Independent explanations by MyBitcoinExplorer. Not affiliated with or endorsed by Bitcoin Core. Guides are educational and do not replace the source or its tests.
Bitcoin Core source © its contributors, distributed under the MIT license. Original notices and bundled third-party licenses are retained in the source tree.