Segregated Witness is cool

Pieter Wuille gave a fantastic presentation on “Segregated Witness” in Hong Kong. It’s a great idea, and should be rolled into Bitcoin as soon as safely possible. It is the kind of fundamental idea that will have huge benefits in the future. It also needs a better name (“segregated” has all sorts of negative connotations…).

You should watch Pieter’s presentation, but I’ll give a different spin on explaining what it is (I know I often need something explained to me a couple different ways before I really understand it).

So… sending bitcoin into a segregate witness-locked output will look like a weird little beastie in today’s blockchain explorers– it will look like an “anyone can spend” transaction, with a scriptPubKey of:

PUSHDATA [version_byte + validation_script]

Spends of segregated witness-locked outputs will have a completely empty scriptSig.

The reason that is not insane is because the REAL scriptSig for the transaction will be put in a separate, new data structure, and wallets and miners that are doing validation will use that new data structure to make sure the signatures for the transaction are valid, etc.

That data structure will be a merkle tree that mirrors the transaction merkle tree that is put into the block header of every block. Every transaction with a segregated witness input will have an entry in that second merkle tree with the signature data in it (plus 10 or so extra bytes per input to enable fraud proofs).

The best design is to combine the transaction and segregated witness merkle trees into one tree, with the left side of the tree being the transaction data and the right side the segregated witness data. The merkle root in the block header would just be that combined tree. That could (and should, in my opinion) be done as a hard fork; Pieter proposes doing it as a soft fork, by stuffing the segregated witness merkle root into the first (coinbase) transaction in each block, which is more complicated and less elegant but means it can be rolled out as a soft fork.

Regardless of how it is rolled out, it would be a smooth transition for wallets and most end-users– if you don’t want to use newfangled segregated witness transactions, you don’t have to. Paying to somebody who is using the newfangled transactions looks just like paying to somebody using a newfangled multisig wallet (a ‘3something’ BIP13 bitcoin address).

There is no requirement that wallets upgrade, but anybody generating a lot of transactions will have a strong incentive to produce segregated witness transactions– Pieter proposes to give segregated witness transactions a discount on transaction fees, by not completely counting the segregated witness data when figuring out the fee-per-kilobyte transaction charge.

So… how does all of this help with the one megabyte block size limit?

Well, once all the details are worked out, and the soft or hard fork is past, and a significant fraction of transactions are spending segregated witness-locked outputs… more transactions will fit into the 1 megabyte hard limit. For example, the simplest possible one-input, one-output segregated witness transaction would be about 90 bytes of transaction data plus 80 or so bytes of signature– only those 90 bytes need to squeeze into the one megabyte block, instead of 170 bytes. More complicated multi-signature transactions save even more.

So once everybody has moved their coins to segregated witness-locked outputs and all transactions are using segregated witness, two or three times as many transactions would squeeze into the one megabyte block limit.

Segregated witness transactions won’t help with the current scaling bottleneck, which is how long it takes a one-megabyte ‘block’ message to propagate across the network– they will take just as much bandwidth as before. There are several projects in progress to try to fix that problem (IBLTs, weak blocks, thin blocks, a “blocktorrent” protocol) and one that is already deployed and making one megabyte block propagation much faster than it would otherwise be (Matt Corallo’s fast relay network).

I think it is wise to design for success. Segregated witness is cool, but it isn’t a short-term (within the next six months to a year) solution to the problems we’re already seeing as we run into the one-megabyte block size limit.