If you’ve been around the cryptocurrency space in the last year or so, you had to notice the insane fees on Bitcoin around December and January. Bitcoin’s adoption has been growing along its price and so the amount of transactions done per day has been going up. There was a point where a day’s worth of transaction costs in USD reached 22 Million dollars. For perspective, it currently averages at 200 thousand dollars, that’s about 99% less.

Now while Bitcoin’s price and the cryptocurrency bear market had a toll on that, last year we saw a massive effort by the Bitcoin community to drive up the number of transactions per second the blockchain could handle. To achieve this goal two strategies were proposed, one of them was Bitcoin Core’s effort introducing SegWit, short for Segregated Witness, which was activated by a user activated soft fork (UASF), and the other was Bitcoin Cash’s user activated hard fork . To further explain this we need to touch on simple basic Bitcoin blockchain technical details.

Bitcoin runs on a blockchain, its a series of connected blocks each building on top of the other by using its hash to make a new hash, in the block is a series of transactions, each transaction contains a list of inputs and outputs, now one of the core consensus rules is that each block, including all the transaction data, block data and meta data, must not exceed 1MB in size. This is one of the core limitations that made Bitcoin unable to accustom to the massive increase in transactions, as there is only one block mined per 10 minutes, the amount of transactions “on the waiting list” far outgrew the amount of transactions that could be included in a block. One simple answer to this would be just to increase the block size limit, and that was the solution Bitcoin Cash came up with, but that solution required something called a hard fork, a hard fork is a change in the Bitcoin protocol that is not backwards compatible, a block after the hard fork may be considered valid although before the fork it was not, so one of the new protocol changes in Bitcoin Cash was to make the block bigger.

The highest recorded block was 4.7MB, although the limit is much higher than that. But one of the drawbacks of Bitcoin Cash is that is was created under political circumstances that were not favorable to the Bitcoin community.

The other solution was Bitcoin Core’s SegWit user activated soft fork, to talk about SegWit we first need to explain a block’s structure a bit, we’re going to focus on the transactions part of the block. Each transaction in a block is represented by the following structure:

Now looking at the transaction, you’ll notice there is not much size to it, it’s a maximum of 26 bytes + the bytes for the list of inputs and outputs, the list of inputs and outputs usually take most of the block, and the core component in each transaction is the input script (also called unlocking scripts, scriptSig or witness). A script is a list of instructions that define how the next person will spend the Bitcoins he received, the script “unlocks” the Bitcoin for spending when that person can provide the public key of the address that received the Bitcoins and a signature that proves that he owns the corresponding private key. The term “witness” is a more general term for an “unlocking script” or “scriptSig”.

Input scripts usually take the most size in Bitcoin blocks and so the creators behind SegWit suggested that they could just take the scripts (witness data) out of the list of inputs and have them placed somewhere else (segregated) instead of being placed in the list of outputs and inputs.

The witness data is another field in the Bitcoin block, and when the block size is calculated the witness is not included in the size, so we can have 1MB full of just inputs, outputs , and other block meta data, without the input scripts (witness) needed to verify and unlock the transactions. This greatly increased the size allowed for the transactions themselves, a max size of 4MB was enforced on the full block including the witness data size.

SegWit did not just increase the amount of transactions that can be relayed per second, it also worked on several problems like transaction malleability, simplifying wallet software and making Lightning network possible.

Transaction Malleability

Transaction malleability was one issue that stuck with Bitcoin ever since its birth, to explain what transaction malleability is let’s use an example. First we need to know that any transaction in Bitcoin has a transaction id “txid”, it’s a double hash of the version, inputs, outputs and locktime of that transaction.

Lets say I got a service from Steve and I have to send 0.5 btc for that service, so I go to my wallet, write up Steve’s address and hit send. My transaction is still not included in any block; me and Steve are just waiting for it to be included and confirmed. While we wait, Steve made a copy of that transaction and changed the script just a bit, not anything that will have any effect on the outcome of the script, just a small change that in turn allows the transaction id to be changed, as the script was a part of the string getting hashed to produce the transaction id, Steve broadcasts his copied transaction and managed to get it included in a block before my transaction did, my wallet will warn me that my transaction failed because my Bitcoins were already spent. Thinking it’s a mistake on my part, I send Steve the money again, and Steve ended up receiving double the amount he was intended to.

Now with SegWit, the input script (witness) was separated from the list of transactions into the witness data, and transactions now have two identifiers, txid and wtxid. So when we take a hash of the transaction to calculate the “txid” we do not include the input script (witness data), we only use the other data that we know can not be tampered with. This simplified wallet software transaction validation as they can now rely on the transaction id being immutable and allowed the Lightning Network to come in place. We’re going to talk about Lightning Network in a future article so stay tuned for that.

Future possiblities

Segwit did not just enable Lightning, it paved the way for many research level efforts to get implemented on the Bitcoin blockchain, one of these effort is MAST or Merkelized Abstract Syntax Trees. This will enable Bitcoin to write smarter contracts. It will be possible by changing the script language version which allows for smaller transaction sizes, more privacy and larger smart contracts. Another is Schnorr Signatures, this technology changes the signature data scheme it changes the signing algorithm, Schnorr signatures have a maximum size less than that of ECDSA, the digital signature algorithm used in Bitcoin. On top of greatly reducing the size of the signature, Schnorr signatures can help in smart contracts and multi signature wallets. SegWit can also help reducing the Unspent Transaction Output Set, which will help miners and full nodes as it will greatly reduce the space needed to run a full node.

Segwit Upgrade

Segwit was applied as a soft fork, an opposite of the hard fork, a soft fork applies a backward compatible change in protocol, that means that a wallet running the old Bitcoin protocol will still see SegWit transactions as valid, it will not properly understand it, but will not reject it.

The soft fork was applied by including an input script as usual but having its value as null, that way old nodes would see a syntactically fine transaction and new nodes would get the block and then ask for the witness data. SegWit activation only happened after 95% of the blocks signaled that they would support it if it was implemented, currently about 33% of all Bitcoin transactions are SegWit transactions and Bitcoin transactions have had average fees in the past few weeks that is the lowest in two years. As more adoption comes to SegWit we could probably be seeing much more cheap microtransactions brought on by Lightning Network. SegWit’s UASF and Bitcoin Cash came in quite a political turmoil but it shows that the community behind Bitcoin was able to find a consensus and is still working hard to make a better payment solution for the world.

Resources

• BIP 141
• BIP 142
• Mastering Bitcoin - Appendix A: Segregated Witness
• Segregated Witness Benefits
• Merklized Abstract Syntax Tree (MAST)
• Transaction Malleability