SegWit and Bitcoin Cash (BCH): A Technical Overview

What is SegWit? #

Since the early days of Bitcoin, its limited scalability has been a point of criticism. The community agreed that the transaction rate needed to increase. In December 2015, Peter Todd published this announcement with an initial test implementation and BIP-141.

During the final implementation of “Segregated Witness” (SegWit for short), a collection of improvements to the Bitcoin protocol emerged, including BIP-65 (CHECKLOCKTIMEVERIFY) and BIP-112 (CHECKSEQUENCEVERIFY), both of which had already been activated.

The best-known new feature of BIP-141 (SegWit) is the separation of transaction data (witness data), allowing more transactions to fit into the familiar 1 MB block size limit while remaining compatible with older clients (a so-called “soft fork”). Outdated nodes on the network see a valid transaction but can no longer fully process it.

Additionally, SegWit aims to prevent “transaction malleability,” the ability to alter already-signed transactions in a way that changes the transaction hash ID despite leaving the original data intact. By eliminating this vulnerability, implementing second-layer systems like the Lightning Network becomes much simpler, potentially enabling very high transaction throughput in the future.

Activation #

Originally, in November 2016, activation of BIP-141 (SegWit) was initiated via BIP-9 (version bits) using version bit 1. This required at least 95% signaling within a given retarget period of 2016 blocks, after which all nodes would activate the system following an additional transition period.

This 95% threshold was not reached for a long time, even as blocks increasingly approached their size limit. Only with the threat of the BIP-148 soft fork, under which users planned to reject all non-signaling blocks from August 1, 2017 onward (which would cause a chain split), were miners able to agree on BIP-91 to avert the looming split.

BIP-91 (Segsignal) was signaled via bit 4. Once 80% signaling was reached, miners would reject all blocks without bit 1 (SegWit signaling) after a short transition period, thereby forcing SegWit activation. The motivation for BIP-91 came from a compromise that called for a hard fork to 2 MB block size three months after activation (SegWit2X).

At the time of writing, the 95% activation threshold has been reached (status = LOCKED_IN) and the transition period under BIP-141 is underway until SegWit is fully activated. Things will get interesting toward the end of the year, when the second part of SegWit2X is planned — which is currently not supported by the Bitcoin Core team.

Update August 24, 2017: SegWit is now fully active!

Compatibility #

Unlike a hard fork, a soft fork is designed to continue “following” the existing rules of the network. Only then can all existing node implementations continue participating in the same network. If, by contrast, a hard fork were to change one of the validity rules (e.g., larger blocks), old nodes would be unable to interpret them and would reject them as invalid. This would cause old clients to continue working on their own chain, splitting the network (chain split).

Bitcoin Cash / Bcash / BCH #

At the same time, supporters of a hard fork planned and executed one. It was designed to allow block sizes of 8 MB and above, and included a more dynamic mining difficulty adjustment to make the fork viable even with lower hashpower.

With block 478559, the first block larger than 1 MB was mined, laying the foundation for the “Bitcoin Cash” fork. Bitcoin Core clients rejected this block as invalid (since it exceeded 1 MB), and the two networks have operated separately ever since.

Because this was a chain split, the UTXOs (unspent transaction outputs (simplified, the “balances” of Bitcoin addresses)) were carried over to the alternative chain. This means that anyone who held the private key for, say, 1 BTC at block 478558 now had both 1 BTC and 1 BCH after the split, which could be moved independently. Different rules applied for bitcoins held on exchanges at the time.