Bitcoin Core version 0.13.1 is now available from:

https://bitcoin.org/bin/bitcoin-core-0.13.1/

This is a new minor version release, including activation parameters for the segwit softfork, various bugfixes and performance improvements, as well as updated translations.

Please report bugs using the issue tracker at github:

https://github.com/bitcoin/bitcoin/issues

To receive security and update notifications, please subscribe to:

https://bitcoincore.org/en/list/announcements/join/

Compatibility

Microsoft ended support for Windows XP on April 8th, 2014, an OS initially released in 2001. This means that not even critical security updates will be released anymore. Without security updates, using a bitcoin wallet on a XP machine is irresponsible at least.

In addition to that, with 0.12.x there have been varied reports of Bitcoin Core randomly crashing on Windows XP. It is not clear what the source of these crashes is, but it is likely that upstream libraries such as Qt are no longer being tested on XP.

We do not have time nor resources to provide support for an OS that is end-of-life. From 0.13.0 on, Windows XP is no longer supported. Users are suggested to upgrade to a newer version of Windows, or install an alternative OS that is supported.

No attempt is made to prevent installing or running the software on Windows XP, you can still do so at your own risk, but do not expect it to work: do not report issues about Windows XP to the issue tracker.

From 0.13.1 onwards OS X 10.7 is no longer supported. 0.13.0 was intended to work on 10.7+, but severe issues with the libc++ version on 10.7.x keep it from running reliably. 0.13.1 now requires 10.8+, and will communicate that to 10.7 users, rather than crashing unexpectedly.

Notable changes

Segregated witness soft fork

Segregated witness (segwit) is a soft fork that, if activated, will allow transaction-producing software to separate (segregate) transaction signatures (witnesses) from the part of the data in a transaction that is covered by the txid. This provides several immediate benefits:

Activation for the segwit soft fork is being managed using BIP9 versionbits. Segwit’s version bit is bit 1, and nodes will begin tracking which blocks signal support for segwit at the beginning of the first retarget period after segwit’s start date of 15 November 2016. If 95% of blocks within a 2,016-block retarget period (about two weeks) signal support for segwit, the soft fork will be locked in. After another 2,016 blocks, segwit will activate.

For more information about segwit, please see the segwit FAQ, the segwit wallet developers guide or BIPs 141, 143, 144, and 145. If you’re a miner or mining pool operator, please see the versionbits FAQ for information about signaling support for a soft fork.

Null dummy soft fork

Combined with the segwit soft fork is an additional change that turns a long-existing network relay policy into a consensus rule. The OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY opcodes consume an extra stack element (“dummy element”) after signature validation. The dummy element is not inspected in any manner, and could be replaced by any value without invalidating the script.

Because any value can be used for this dummy element, it’s possible for a third-party to insert data into other people’s transactions, changing the transaction’s txid (called transaction malleability) and possibly causing other problems.

Since Bitcoin Core 0.10.0, nodes have defaulted to only relaying and mining transactions whose dummy element was a null value (0x00, also called OP_0). The null dummy soft fork turns this relay rule into a consensus rule both for non-segwit transactions and segwit transactions, so that this method of mutating transactions is permanently eliminated from the network.

Signaling for the null dummy soft fork is done by signaling support for segwit, and the null dummy soft fork will activate at the same time as segwit.

For more information, please see BIP147.

Low-level RPC changes

Linux ARM builds

With the 0.13.0 release, pre-built Linux ARM binaries were added to the set of uploaded executables. Additional detail on the ARM architecture targeted by each is provided below.

The following extra files can be found in the download directory or torrent:

ARM builds are still experimental. If you have problems on a certain device or Linux distribution combination please report them on the bug tracker, it may be possible to resolve them. Note that the device you use must be (backward) compatible with the architecture targeted by the binary that you use. For example, a Raspberry Pi 2 Model B or Raspberry Pi 3 Model B (in its 32-bit execution state) device, can run the 32-bit ARMv7-A targeted binary. However, no model of Raspberry Pi 1 device can run either binary because they are all ARMv6 architecture devices that are not compatible with ARMv7-A or ARMv8-A.

Note that Android is not considered ARM Linux in this context. The executables are not expected to work out of the box on Android.

0.13.1 Change log

Detailed release notes follow. This overview includes changes that affect behavior, not code moves, refactors and string updates. For convenience in locating the code changes and accompanying discussion, both the pull request and git merge commit are mentioned.

Consensus

RPC and other APIs

Block and transaction handling

P2P protocol and network code

Build system

GUI

Wallet

Tests and QA

Documentation

Miscellaneous

Credits

Thanks to everyone who directly contributed to this release:

As well as everyone that helped translating on Transifex.