Bitcoin Core 0.13.1 Released with Segregated Witness

We are pleased to release Bitcoin Core 0.13.1, which contains code miners can use to signal support for the segregated witness (segwit) soft fork and which nodes can use to validate segwit transactions if the soft fork is activated.

The segwit soft fork is fully backwards compatible with all Bitcoin wallets, so you will continue to be able to safely send and receive bitcoins whether or not segwit is activated. If you are a miner, you may need to take action if it appears that segwit will activate; for all other Bitcoin users, there is no action you need to take related to segwit now or in the future. However, if you want to support segwit or if you want more details about the changes you may see if segwit activates, please see our segwit upgrade guide.

Segwit timeline:

# Miners will be able to signal that they are willing and able to enforce segwit starting at the beginning of the first 2,016-block retarget period on or after 15 November 2016 (UTC).

# If 95% of blocks within any retarget period signal support for segwit, it locks-in.

# After another 2,016-block (roughly two week) retarget period, segwit will activate, allowing miners to produce blocks containing segwit transactions on Bitcoin’s mainnet.

# If segwit has not activated by the end of one retarget period after 15 November 2017, segwit will cease to be eligible for activation.

If segwit is activated, transaction-producing software will be able 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:

Elimination of unwanted transaction malleability for transactions that use segregated witnesses, making it easier to write Bitcoin wallet software and simplifying the design of smart contracts for Bitcoin.

Capacity increase allowing blocks to hold more transactions than before.

Weighting data based on how it affects node performance so that miners are allowed to include more data in the parts of the block that don’t reduce node performance long-term.

Signature covers value to reduce the number of steps secure signature generators (such as hardware wallets) need to perform to create a secure signature. This makes it easier to develop hardware wallets and may significantly improve the speed of existing hardware wallets.

Linear scaling of sighash operations to ensure that transactions using segwit can’t trigger the problem that caused a block in 2015 to take 25 seconds to validate.

Increased security for multisig so security goes from about 80 bits with P2SH to about 128 bits with segwit—which is about 281 trillion times more security against certain attacks.

More efficient almost-full-node security to allow newly-started nodes who are willing to give up some security guarantees to build an accurate copy of the Bitcoin ledger without having to download all the data from every block. (This is a feature made possible by segwit; it is not included in Bitcoin Core 0.13.1.)

Script versioning to allow users to individually opt-in to future soft fork changes made to Bitcoin’s scripting language.

For more information about each of the benefits above, please see the detailed segwit benefits section below or the longer and more detailed segwit benefits FAQ page on this website.

For more information about upgrading for segwit, please see the segwit upgrade guide.

Detailed segwit benefits

The following subsections describe in more detail the features that were summarized above.

1. Elimination of unwanted transaction malleability

Segregating the witness allows both existing and upgraded software to calculate the transaction identifier (txid) of transactions without referencing the witness, which can sometimes be changed by third-parties (such as miners) or by co-signers in a multisig spend. This solves all known cases of unwanted transaction malleability, which is a problem that makes programming Bitcoin wallet software more difficult and which seriously complicates the design of smart contracts for Bitcoin.

2. Capacity increase

Segwit transactions contain new fields that are not part of the data currently used to calculate the size of a block, which allows a block containing segwit transactions to hold more data than allowed by the current maximum block size.

Estimates based on the transactions currently found in blocks indicate that if all wallets switch to using segwit, the network will be able to support about 70% more transactions. The network will also be able to support more of the advanced-style payments (such as multisig) than it can support now because of the different weighting given to different parts of a transaction after segwit activates (see the following section for details).

3. Weighting data based on how it affects node performance

Some parts of each Bitcoin block need to be stored by nodes in order to validate future blocks; other parts of a block can be immediately forgotten (pruned) or used only for helping other nodes sync their copy of the block chain.

One large part of the immediately prunable data are transaction signatures (witnesses), and segwit makes it possible to give a different “weight” to segregated witnesses to correspond with the lower demands they place on node resources. Specifically, each byte of a segregated witness is given a weight of 1, each other byte in a block is given a weight of 4, and the maximum allowed weight of a block is 4 million. Weighting the data this way better aligns the most profitable strategy for creating blocks with the long-term costs of block validation.

4. Signature covers value

A simple improvement in the way signatures are generated in segwit simplifies the design of secure signature generators (such as hardware wallets), reduces the amount of data the signature generator needs to download, and allows the signature generator to operate more quickly. This is made possible by having the generator sign the amount of bitcoins they think they are spending, and by having full nodes refuse to accept those signatures unless the amount of bitcoins being spent is exactly the same as was signed.

For non-segwit transactions, wallets instead had to download the complete previous transactions being spent for every payment they made, which could be a slow operation on hardware wallets and in other situations where bandwidth or computation speed was constrained.

5. Linear scaling of sighash operations

In 2015 a block was produced that required about 25 seconds to validate on modern hardware because of the way transaction signature hashes are performed. Other similar blocks, or blocks that could take even longer to validate, can still be produced today. The problem that caused this can’t be fixed in a soft fork without unwanted side-effects, but transactions that opt-in to using segwit will now use a different signature hashing method that doesn’t suffer from this problem and doesn’t have any unwanted side-effects.

6. Increased security for multisig

Bitcoin addresses (both P2PKH addresses that start with a ‘1’ and P2SH addresses that start with a ‘3’) use a hash function known as RIPEMD-160. For P2PKH addresses, this provides about 160 bits of security—which is beyond what cryptographers believe can be broken today. But because P2SH is more flexible, only about 80 bits of security is provided per address.

Although 80 bits is very strong security, it is within the realm of possibility that it can be broken by a powerful adversary. Segwit allows advanced transactions to use the SHA256 hash function instead, which provides about 128 bits of security (that is 281 trillion times as much security as 80 bits and is equivalent to the maximum bits of security believed to be provided by Bitcoin’s choice of parameters for its Elliptic Curve Digital Security Algorithm [ECDSA].)

7. More efficient almost-full-node security

Satoshi Nakamoto’s original Bitcoin paper describes a method for allowing newly-started full nodes to skip downloading and validating some data from historic blocks that are protected by large amounts of proof of work. Unfortunately, Nakamoto’s method can’t guarantee that a newly-started node using this method will produce an accurate copy of Bitcoin’s current ledger (called the UTXO set), making the node vulnerable to falling out of consensus with other nodes.

Although the problems with Nakamoto’s method can’t be fixed in a soft fork, segwit accomplishes something similar to his original proposal: it makes it possible for a node to optionally skip downloading some blockchain data (specifically, the segregated witnesses) while still ensuring that the node can build an accurate copy of the UTXO set for the block chain with the most proof of work. Segwit enables this capability at the consensus layer, but note that Bitcoin Core does not provide an option to use this capability as of this 0.13.1 release.

8. Script versioning

Segwit makes it easy for future soft forks to allow Bitcoin users to individually opt-in to almost any change in the Bitcoin Script language when those users receive new transactions. Features currently being researched by Bitcoin Core contributors that may use this capability include support for Schnorr signatures, which can improve the privacy and efficiency of multisig transactions (or transactions with multiple inputs), and Merkelized Abstract Syntax Trees (MAST), which can improve the privacy and efficiency of scripts with two or more conditions. Other Bitcoin community members are studying several other improvements that can be made using script versioning.

How segwit was tested

Developers from Bitcoin Core and a number of other Bitcoin projects have been testing and using one version of segwit or another since June 2015—and have been testing the final version of segwit implementation since April 2016. A few of the development and testing milestones are described below:

June 2015 saw the release of the Elements Project sidechain, which included a version of segwit described as being “from scratch” because it wasn’t intended to be compatible with previous Bitcoin software as it wasn’t known how to do that at the time. This version of segwit continued to be used on Elements-based sidechains until recently, when the Elements Project switched to using the version provided by Bitcoin Core 0.13.1 because of the comprehensive testing it received as well as its compatibility with existing Bitcoin software.

October 2015 was when a developer described how segwit could be implemented in Bitcoin as a soft fork. Developers with experience developing the “from scratch” version immediately began designing a soft fork implementation that is backwards compatible with all existing Bitcoin software (although programs do need to upgrade to fully understand segwit).

December 2015 ended with the launch of a special segwit-specific testnet (called segnet) that allowed implementers and testers to run segwit in a multi-user environment, and which also allowed wallet authors to test their code for generating segwit transactions. Segnet went through several iterations as problems were found and fixed, and as improvements were discovered and implemented.

April 2016 opened with a pull request for segwit made to Bitcoin Core, and all Bitcoin developers from any project were encouraged to provide feedback (and many did).

May 2016 marked the activation of segwit on Bitcoin’s testnet. This provided a live integration test of Bitcoin Core’s implementation against the large variety of other software on testnet to see if it there were any problems interoperating with other software that had upgraded to segwit or whether any problems appeared in programs that had not been upgraded for segwit. The success of this testing helped demonstrate that segwit would not cause problems for anyone (besides miners) who does not upgrade when segwit activates. As of the Bitcoin Core 0.13.1 release, segwit has been activated for over six months on testnet with no known consensus failures.

Also in May 2016, twenty Bitcoin Core developers met in Switzerland for (among other things) an in-person review of the segwit code and ensuring that test coverage was adequate.

June 2016 saw the completion of the segwit code review, with several experienced Bitcoin developers completing their reviews and indicating support for segwit’s code changes.

Also in June was the merge of compact blocks, a peer-to-peer protocol enhancement based on developments made over the last several years in the Fast Block Relay Network. Compact blocks allows more efficient announcements of new blocks between cooperating peers, which is expected to minimize the bandwidth and latency impact of the larger blocks allowed for by segwit.

September 2016 saw adoption of Bitcoin Core 0.13.0 (containing compact blocks) starting to be used in production, with over 1,300 Bitcoin Core 0.13.0 nodes accepting incoming connections by the end of the month. Also by the end of the month, a number of programs besides Bitcoin Core—including the btcd full node and many commonly-used mining programs—had code ready to upgrade to segwit and were actively being used to generate blocks on testnet.

Null dummy soft fork

Also in Bitcoin Core 0.13.1 and 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.

Conclusion

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

Bitcoin Core 0.13.1 is the only soft fork release planned for the 0.13 release series. The next major planned release is Bitcoin Core 0.14.0, which has feature freeze scheduled for mid-January 2017 and release to follow after all testing is completed (this typically takes more than a month in order to give everyone sufficient time to test).

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: