If one proposal excited attendees at the recent Scaling Bitcoin workshop in Hong Kong, Bitcoin Core and Blockstream, it was developer Dr. Pieter Wuille's Segregated Witness. Praised by many within the technical community, Segregated Witness is expected to improve Bitcoin's performance in a number of ways, while some even hope it might be the scaling solution that helps bring some peace back to the Bitcoin community.
The first part of our three-part Segregated Witness series covered how it works. In this second part: What it does.
Increasing the Effective Block Size Without Increasing the Block-size Limit
The benefit of Wuille's Segregated Witness proposal that has perhaps drawn most attention, is that the removal of signatures from 1 megabyte blocks could effectively increase Bitcoin’s block size. This means more transactions per second can be recorded on the blockchain, or in other words, it would allow for a higher transaction throughput. It could do so, moreover, without breaking any of the existing consensus rules - including the block size limit.
Wuille's proposal does introduce a new type of maximum block size. The formula used to calculate this limit is set somewhat arbitrarily: A block without
the Segregated Witnesses, plus a quarter
of the Segregated Witnesses, must not exceed 1 megabyte. As such, all blocks will seem smaller than 1 megabyte to old nodes, since a quarter of the Segregated Witness (which they don't see) needs to fit in that same 1 megabyte. New nodes will meanwhile see blocks that exceed 1 megabyte, since the actual
size of the Segregated Witness is larger than the quarter accounted for.
The exact amount of additional space Segregated Witness opens up depends on the types of transactions new blocks include. If more transactions store more data in the Segregated Witness, as multisig transactions would do, the total size of new blocks increases. This adds up to a new maximum block size of about 1.75 megabyte for normal transactions, and 4 megabyte as a hard cap that’s impossible to exceed even if (almost) all data is squized into the Segregated Witness.
Say Goodbye to Transaction Malleability
But there's another, perhaps even greater advantage: Segregated Witness could take care of Bitcoin's transaction malleability. In fact, this was the original motivation for Wuille and others to explore the Segregated Witness concept.
Transaction malleability is caused by a cryptographic trick to change a signature, without changing what that signature stands for. This can be done, moreover, without the private key used to create the original signature. In Bitcoin's case, this means that anyone can pick any transaction from the peer-to-peer network, and alter the signature into an equally valid signature. This new signature still reflects the exact same data it originally signed, and it can still be verified using the same public key. It doesn't change what a transaction does at all. But because it looks different, it does completely change the transaction ID.
Transaction malleability causes two main problems. First, it messes up the accounting of Bitcoin software that uses transaction IDs to verify whether transactions are confirmed. But perhaps more importantly, transaction malleability severely limits the potential of all sorts of advanced Bitcoin tricks that build on unconfirmed transactions (using their IDs), such as payments channels and the Lightning Network.
Of course, Segregated Witness pulls signatures out of the part of the transaction used to create the transaction ID. So while the signatures in the Segregated Witness could still be changed, this would not affect Bitcoin software using transaction IDs, nor would it matter for payments channels or the Lightning Network, thus setting the stage for the roll-out of additional scaling layers.
Script Versions, or How Bitcoin Can Learn to do Almost Anything
A third advantage of Wuille's Segregated Witness proposal has Bitcoin programmers just as excited as the first two – if not more-so: script versions.
As explained in the previous article, Segregated Witnesses carry scriptSigs that unlock bitcoin. But they carry something else, too: version bytes. These version bytes preface scriptSigs in Segregated Witnesses, indicating what kind of scriptSig it is. If a node reading the version byte recognizes the type, it can tell what requirements must be met to unlock bitcoin in the scriptSig. If a node reading the version byte does not
recognize the type, it interprets the scriptSig as an “Anyone can spend.”
This opens up all sorts of new ways to lock bitcoin up in transactions. In fact, it can be used to lock bitcoin up in any way developers come up with. As such, it's impossible to explain how this will be used in the future, since much of this still needs to be invented. But initial ideas include Schnorr signatures, which are much faster to verify than signatures currently in use, and more complicated types of multisig transactions; perhaps even Ethereum-like scripts.
And importantly: Like Segregated Witness itself, these types of upgrades will not break Bitcoin's existing consensus rules. Rather than every single Bitcoin node, only a majority of miners needs to adapt, making them much easier to deploy.
Fraud proofs: the Completion of Satoshi's Vision for SPV
We're not done yet. Segregated Witness could also introduce something called fraud proofs. Originally envisioned by Satoshi Nakamoto, fraud proofs could significantly improve the security of SPV-nodes (or: “light wallets”); Bitcoin nodes that do not verify all transactions on the network or store the complete blockchain.
To check whether a transaction has taken place, SPV-nodes merely scan the blockchain for the relevant transaction ID. If they find it, that means a miner included the transaction in a block. But SPV-nodes do not validate whether the transaction adhered to Bitcoin’s consensus rules. As such, SPV-nodes trust miners to play fair, rather than verify they do. In a worst case scenario, this could even mean that miners pay SPV-nodes with bitcoin created out of nothing, for instance by creating transactions with no inputs, or by awarding themselves excess fees in the coinbase transaction.
These types of problems could be solved by requiring miners to include extra data in the Segregated Witness Merkle Tree, specifying where the bitcoin locked up in all transactions came from, exactly. That way, if a block contains invalid transactions, a short and easy-to-check fraud proof can be constructed by any full node. This full node can send the fraud proof to SPV-nodes, so they know to reject the block.
That said, even with fraud proofs, SPV-nodes would not quite offer the same level of security as full nodes. Most importantly, the fraud proof solution requires that SPV-nodes can communicate with the network free from censorship. (For instance: censorship from government-sanctioned ISPs.) Additionally, SPV-nodes need at least one full node on the network to actually produce the fraud proofs.
Storage
Finally, Segregated Witness could decrease the amount of data Bitcoin nodes need to store on their hard drives. This, again, reduces the burden of running a full node, and brings down the time it takes to sync a node with the network when first installed.
While full nodes typically store all transaction data for all of Bitcoin's history, signatures are reasonably considered expendable after a certain amount of time has passed. Once a transaction is considered valid, confirmed into a block, and secured in the blockchain with proof of work for – say – a year, it could only have been fraudulent if miners were collectively mining on an invalid chain for all that time, and presumably without anyone noticing.
Of course, ridding the blockchain of older signatures is not a purist's ideal, as he might want to verify old transaction data regardless. Fortunately, that's not likely to become a problem either. All it requires is one such purist to seed the Segregated Witness data for everyone else to download.
The third part of this three-part story will explore exactly what Segregated Witness means for the long-lasting block-size dispute. Thanks go out to Blockstreamdevelopers Pieter Wuille and Mark Friedenbach andCiphrex CEO Eric Lombrozo for provided information and added feedback – not to mention a lot of patience.