The Segregated Witness proposal by Pieter Wuille is the best news coming out of the Scaling Bitcoin workshop that just wrapped up in Hong Kong.

The bitcoin community has been divided over how to increase the current 1 MB block size limit that is hard coded into the bitcoin client. Everyone seems to agree that an increase is important and needed now. But it has always been assumed that a hard fork in the software would be required. The most controversial proposal was Mike Hearn’s Bitcoin XT. Bitcoin XT never gained traction with bitcoin mining pools and is basically DOA.

We all were looking forward to the Hong Kong conference with hopes that a solution to increasing the block size would emerge from debate. One that was acceptable to all the major players. Especially Chinese mining pools.

Pieter Wuille pulled the proverbial rabbit out of his hat and wowed the conference with his Segregated Witness proposal. Segregated Witness is a way to increase the ability of bitcoin to handle more transactions per second equivalent to a 4 MB blocksize but without a contentious hard fork. Segregated Witness can be brought into bitcoin using a soft fork and does not require approval by a majority of bitcoin miners.

So how does Segregated Witness accomplish an increase in transaction volume without the dreaded hard fork?

ELI5: Segregated Witness Proposal

Segregated Witness increases the space available in current 1 MB blocks for transactions. It does this by reorganizing data to handle the transaction signatures separately. Here is an interactive graphic from the presentation in Hong Kong:

A bitcoin transaction contains four elements or data fields. The first is the amount of bitcoin. The second is one or more inputs showing the addresses the bitcoin came from. Third is one or more outputs showing the addresses bitcoin will be sent to. Lastly is the signature that “witnesses” the sender is authorized to make the transaction.

At present the signatures are included in the “from” data fields along with transaction id. Segregated Witness moves the signatures from the transaction data fields freeing up space for more transactions.

So where do the signatures go? Segregated Witness puts the signatures into a separate storage area in a Merkle tree in the input of the transaction. At present signatures take up 60% of the blockchain. With Segregated Witness the bitcoin client would not see the signature data as it would be stored in an area they do not recognize.

Transactions would appear smaller and more could be included in a block. The net effect would be a 2X capacity increase in transactions per second. This would be equivalent to a 4 MB block size and would only require a soft fork to implement.

The Segregated Witness BIP is being written now and should be published within a month. The proposal was warmly received at the conference. The recommendation from Gregory Maxwell is that it be adopted immediately. Gavin Andresen just published a blog post in favor of Segregated Witness.

Side benefits of adopting Segregated Witness into Bitcoin Core are:

  1. Full nodes could skip transferring old signatures.
  2. It allows for SPV or lite nodes to have fraud proofs.
  3. Most important it is one of three soft forks (others are BIP65 and BIP112) required for Lightning Network to be deployed.

With both Segregated Witness, BIP65 and BIP112 merged into Bitcoin Core Lightning can then be deployed and payment channels start to be used to replace on chain transactions.

Segregated Witness will provide much needed space in the blockhain for more transactions per second. However, a separate hardfork will most likely still be required, but later in the future. As a bonus it will also solve the transaction malleability problem once and for all.


On December 22, 2015 the Capacity Increases FAQ was published by the core developers outlining the roadmap to deployment of Segregated Witness by a soft fork expected in April 2016.


CONSENSUS BIP: witness structures and how they’re committed to blocks, cost metrics and limits, the scripting system (witness programs), and the soft fork mechanism. Draft already submitted pending BIP number assigment.

PEER SERVICES BIP: relay message structures, witnesstx serialization, and other issues pertaining to the p2p protocol such as IBD, synchronization, tx and block propagation, etc. Draft in progress.

APPLICATIONS BIP: scriptPubKey encoding formats and other wallet interoperability concerns. Draft in progress.