We’re pleased to announce the official release of Bitcoin Core 0.13.0. During the six-month development cycle leading to this release, dozens of contributors have made hundreds of notable improvements to Bitcoin Core. Among the many upgrades available in this release, the following may be especially interesting to miners, node operators, and wallet users:

Preparation for segregated witness to increase capacity, eliminate unwanted transaction malleability, and enable new ways to upgrade Bitcoin’s Script language using soft forks. The code in this release prepares for segwit only; it does not support segwit on mainnet, so users who want segwit support will need to upgrade to a future version.

Compact block relay on the peer-to-peer network to eliminate a major source of redundant data transfer among nodes that relay transactions, as well as reduce the peak amount of bandwidth those nodes use when downloading newly-generated blocks.

Fee-based filtering to eliminate another source of unnecessary data transfer on the peer-to-peer network by allowing nodes to skip relaying any unconfirmed low-fee transactions that they know their peers would ignore anyway.

BIP32 HD wallet support in Bitcoin Core’s built-in wallet to allow users to backup every private key they will ever generate with the wallet rather than the old default of just the next 100 private keys.

Child Pays For Parent (CPFP) transaction selection to allow miners to mine more profitably (when possible) and give users the ability to incentivize mining of selected transactions in cases where the users can’t increase transaction fees directly.

Official Bitcoin Core binary executables for ARM chipsets used with Linux to allow users of those platforms to take advantage of pre-built software secured by the Gitian deterministic building and multiple attestation process.

For a more comprehensive list of the changes made in Bitcoin Core 0.13.0, please see the release notes. The improvements listed above are described in more detail below.

Preparation for segregated witness

The most significant code change made in Bitcoin Core 0.13.0 is the inclusion of the segregated witness (segwit) code in preparation for an upcoming soft fork. Please note that this release will not activate segwit, and if segwit is activated, this release will not act any differently, so those who want to use or enforce segwit will need to upgrade to a later release that does contain the activation mechanism.

By including the segwit code in Bitcoin Core 0.13.0, users gain several advantages:

Easier upgrade to segwit: The code differences (“diff”) from this release to a subsequent release that includes segwit will be small. This allows users who modify their version of Bitcoin Core to easily convert any modifications they make to Bitcoin Core 0.13.0 to the release that contains segwit (which is expected to be 0.13.1). Easier segwit testing: Although this release won’t run segwit code on mainnet, it does run the code on testnet and in regression testing mode (regtest), which makes it easy for developers, administrators, and testers to use segwit in a safe environment with a version of Bitcoin Core that will be very close to the first version that is ready for miners to activate segwit. Full integration with other features: all the other features included in this release – such as feefiltering, compact block relay, child-pays-for-parent mining, and official binaries for Linux on ARM – are integrated with the segwit code and will probably be in production for two or more months before segwit activates, providing extra time for potential problems to be discovered through community review and testing.

More information:

Compact block relay

Prior to Bitcoin Core 0.13.0, a running full node would (by default) receive many transactions twice:

Before the transaction was confirmed, as an individual transaction being relayed across the network. After the transaction was confirmed, as part of a group of transactions contained in a newly-mined block being relayed across the network.

There’s no need for the node to receive the transaction a second time if it still has the first copy. Compact block relay (BIP152) can eliminate this redundancy by allowing a node to receive from its peers an ordered list of what transactions are included in a new block. With this knowledge, the node can use the transactions it has already received to partly or fully reconstruct the transactions part of the block for itself. If the node doesn’t receive all the transactions it needs to fully reconstruct the block, it requests the missing transactions from its peers, and then uses them to complete the block.

Compact blocks provides three very important benefits to the network:

By reducing the amount of bandwidth used by transaction relay nodes, compact blocks help offset the expected increase in bandwidth that will occur when the segwit capacity increases are enabled by miners. This offset should allow nodes to continue operating on the network after segwit even if they’re presently near their current bandwidth caps. By eliminating the bandwidth spike that occurs when nodes receive a new block, compact blocks may make it easier to keep a node operating on connections with limited peak bandwidth. For example, several users have reported that receiving a new block slows down other important activity on their network, such as video conferencing, so some of those users shut down Bitcoin Core before starting those activities. Compact blocks may eliminate those bandwidth spikes and make running Bitcoin Core less inconvenient for those users. Faster propagation of blocks across the network, by dramatically reducing the amount of data that needs to be transported when a new block is found.

More information:

Release notes

Compact Block Relay FAQ

BIP152, which describes the compact blocks protocol

Bitcoin FIBRE, an open source protocol and implementation that builds upon compact blocks to minimize latency for new block announcements between peers on managed networks. FIBRE was designed and implemented alongside compact block relay version 1 and it is being used to test improvements for a subsequent version of compact block relay.

Fee filtering

For several years now, Bitcoin Core nodes have used a minimum relay fee rate to help determine what unconfirmed transactions they’ll process, relay, and store in their individual memory pools. Each node gets to decide its own minimum relay fee rate, and if they receive a transaction whose fee rate is below that limit, they don’t add it to their memory pools or relay it to their other peers (although another mechanism called transaction priority historically allowed some transactions that pay a low fee to be accepted into mempools and relayed).

Prior to Bitcoin Core 0.13.0, nodes didn’t tell each other what minimum fee rate they were using, which could lead to wasted bandwidth. For example, Alice sends Bob a transaction without realizing that the transaction’s fee rate is below Bob’s minimum. Because of the way Bitcoin transactions are relayed, Bob has no way of knowing that the transaction is below his limit until he has already downloaded the whole transaction, at which point he stops processing the transaction because its fee rate is too low, so both his bandwidth and Alice’s bandwidth end up being wasted.

Bitcoin Core 0.13.0 supports a new message that has been added to the peer-to-peer (P2P) protocol, the feefilter message, which has been designed to help eliminate this wasted bandwidth. This P2P message allows Bob to tell Alice what he is currently using as his minimum relay fee rate so that Alice will not bother trying to relay to him any transactions that pay a fee below his rate.

More information

BIP32 HD wallet support

When Bitcoin Core starts for the first time, it will now generate a BIP32 Hierarchical Deterministic (HD) wallet where every private key in the wallet is derived from a single piece of information using a repeatable (deterministic) process. This means backing up that single piece of information will back up every private key your wallet will ever generate, ensuring that you can recover any bitcoins controlled by those private keys in the future.

Backups are hard to get right, so please note the following information:

If you upgrade from any version of Bitcoin Core before 0.13.0, you will continue using the old style of wallet where each private key is generated individually, with (by default) up to 100 of them pre-generated in advance to make backups easier—meaning you need to create additional backups every 100 transactions, since each default-style transaction uses one private key.

If you create a new wallet with 0.13.0 (or above) and you change from the default unencrypted wallet to an encrypted wallet, a new HD wallet will be generated for you. You will still have access to any bitcoins sent to the unencrypted wallet, but you will need to backup the wallet again.

If you aren’t sure whether you’re using an HD wallet, you can check using the getwalletinfo RPC:

If you use the Bitcoin Core graphical user interface, you can click the Help menu, choose the Debug option, click the Console tab, and then type in getwalletinfo .

If you use the bitcoin-cli command to access the RPC interface, you can type bitcoin-cli getwalletinfo .

In either case, if you see a line labeled “masterkeyid”, then you’re using an HD wallet; if you don’t see it, then you’re using a wallet with individually generated keys.

Backing up an HD wallet ensures that you will be able to re-generate any private keys produced by that wallet in the future, but that is the only information you can recover from the backup in the future. Any additional information you enter into your wallet after you make the backup, such as descriptions of transactions you sent or received, will be lost if you have to restore from the HD wallet backup, so we recommend that you continue to make regular backups of your wallet in order to preserve that information.

Importantly, if you manually import any private keys to your wallet, they cannot be recovered using any backups made prior to the import, so you will need to make a new wallet backup and use that.

More information

More intelligent transaction selection for mining

Ancestor fee rate mining is the new default transaction selection method for mining in Bitcoin Core 0.13.0. Miners can use it to select which transactions to put in their next block, providing two important benefits:

For miners often more revenue can be earned from transaction fees per block because ancestor fee rate mining is able to prioritize certain higher-fee transactions. For users as a side benefit of miners choosing transactions more intelligently, it becomes possible for the recipient of an unconfirmed transaction to incentivize miners to mine that transaction.

Bitcoin has rule that says if Alice spends a bitcoin to Bob, the transaction where Alice originally receives the bitcoin must appear earlier in the blockchain than the transaction where she spends that bitcoin to Bob. In other words, the parent transaction must appear earlier in the blockchain than its child transaction, forming an ancestor relationship.

Both the child and parent transactions can appear in the same block, but if they do, the parent must appear earlier in that block than the child. This means that if an unconfirmed child transaction pays a high fee, miners should be incentivized by this existing Bitcoin rule to mine that transaction’s unconfirmed parent (even if it pays a low fee) in order to get the child’s high fee.

This incentivization scheme is often called Child Pays For Parent (CPFP). In the simplest version, miners group a transaction and all of its ancestors together, calculating their total fee-per-byte in order to determine whether mining them together pays a high enough fee to outbid other individual transactions the miner wants to include in its next block.

A key advantage of ancestor fee rate mining is that the two transactions don’t need to be created by the same person. For example, if Bob is waiting for confirmation of a transaction that Alice sent him, Bob can independently create a child transaction that incentivizes miners to confirm his transaction and Alice’s transaction together.

It is important to note that ancestor fee rate mining doesn’t guarantee that a low-fee transaction will be mined just because it has a high-fee child or other descendent. In particular, almost all miners and nodes will ignore transactions that don’t pay a minimal amount of fee per kilobyte of data (the exact ratio varies by node), so if a parent transaction is ignored because the fee it pays is below this limit, then its children will not be mined no matter how high a fee they pay.

More information:

Official builds for Linux on ARM

The official Bitcoin Core binaries built and cryptographically signed by multiple contributors through the Gitian process now includes two new platforms:

bitcoin-${VERSION}-arm-linux-gnueabihf.tar.gz: Linux binaries for the most common 32-bit ARM architecture.

bitcoin-${VERSION}-aarch64-linux-gnu.tar.gz: Linux binaries for the most common 64-bit ARM architecture.

If you have the GNU C compiler installed, you can run the following command to figure out which platform you’re using:

gcc -print-multiarch

Or you if use a Debian-based system, you can try the following command:

dpkg-architecture -q DEB_HOST_GNU_SYSTEM

These binaries are designed for Linux using GNU libc6; they are not expected to run by default on Android or other operating systems.

The new builds are still experimental, so please report any problems that you encounter.

More information

Release notes

The Bitcoin Wiki has a list of Bitcoin Core compatible devices. Please add any unlisted devices that are also compatible.

The Debian Wiki includes information about boards that are probably compatible with these builds: 32-bit arm-linux-gnueabihf and 64-bit aarch64-linux-gnu

Conclusion

For details on all the changes made in Bitcoin Core 0.13.0, please read the release notes. To download, please visit the download page or the files directory

With the release of Bitcoin Core 0.13.0, we begin the six-month release cycle for the next version of Bitcoin Core (expected to be 0.14.0). With the participation of the community, we will also be choosing the BIP9 parameters for segregated witness and releasing a minor version (expected to be 0.13.1) with segwit fully enabled.

If you are interested in contributing to Bitcoin Core, please see our contributing page and the document How to contribute code to Bitcoin Core. If you don’t know where to get started or have any other questions, please stop by our IRC chatroom and we’ll do our best to help you.

Hashes for verification

These are the SHA-256 hashes of the released files: