When we look back at the history of Bitcoin, 50 years from now on, one of the most significant chapter will be the block-size debate. In the short history of cryptocurrencies, no other issue has been as passionately and vigorously debated as the block-size debate. Battle lines have been drawn and two cabals “pro block increase” and “anti-block increase” have been created.
In this guide, we are going to talk about the block-size debate and all that came out of it, with a significant focus on segregated witness or SegWit.
Bitcoin and Blocks
So what exactly do we mean by blocks and block size?
When Satoshi Nakamoto released his Bitcoin whitepaper, he introduced the world to Bitcoin and the Blockchain Technology.
A blockchain is, in the simplest of terms, a time-stamped series of immutable record of data that is managed by a cluster of computers not owned by any single entity. Each of these blocks of data (i.e. block) are secured and bound to each other using cryptographic principles (i.e. chain).
For a more visual representation, check out the following diagram:
So, to put it simply, a blockchain is a series of blocks where each new block carries the hash of the previous block. Newer blocks are added to the blockchain by a consensus mechanism like proof of work, proof of stake etc. In a Bitcoin blockchain, which uses proof-of-work, we have nodes called “miners” who “mine” for these blocks by using their computational power to solve extremely hard cryptographic puzzles.
Once they have mined these blocks, they can become temporary dictators of the blocks. What do we mean by that?
By mining a block, a miner is responsible for putting individual transactions inside the blocks that they have mined. For putting each transaction in, they can command a transaction fee, which can be thought of like a toll. So, to reiterate, blocks are individual elements in a blockchain, which are discovered and maintained by miners/validators and contain individual transaction elements.
Now, there is only so much data that you can stuff inside these blocks. And this is where we come to the next part of our discussion.
Blocksize and Scalability
Back when Satoshi Nakamoto created Bitcoin, he was forced to impose a 1 MB limit on the Bitcoin blocks. He envisioned that Bitcoin blocks may get filled with spam transactions and that would lead to DoS (Denial of Service) attacks.
While the block limit may have worked, unfortunately, this led to a problem. Bitcoin became popular! And as a result, it just didn’t have the provisions required to keep up with the increasing demand. Check out this graph (via Blockchain.info):
That graph shows the increasing amount of transactions per month since 2009 and as you can see, the increase has been pretty drastic. Now, this is obviously good news, right? After all, it just goes to show that more and more people are getting into this space and that cryptocurrencies are getting the mainstream condition. However, what this has unfortunately led to is a decrease in the speed of the overall system.
Bitcoin’s and a part of Ethereum’s utility is as a payment protocol. As such, it is only fair that we compare them to other similar and popular payment protocols. Think of mainstream payment protocols like visa and PayPal. While Visa manages a whopping 1667 transactions per second, Paypal still manages to do a respectable 193 transactions per second. So, how do you think Bitcoin and Ethereum do in that regard?
Well…Bitcoin does a miserable 7 transactions per second while Ethereum manages 20. Now, these are certainly not good numbers and they are really not going to help cryptocurrencies in the long run. The only way that these numbers can be improved is if they work on their scalability.
If we were to categorize the main scalability problems in the cryptocurrencies, they would be:
- The time it takes to put the transaction inside the block
- The time that it takes to reach a consensus.
The Time Taken To Put A Transaction In The Block
When you deal with fiat currency, you can simply conduct transactions by physically sending money to one another. However, that is not really the case with digital currencies like Bitcoin and Ethereum. In these cryptocurrencies, we have people called miners who actually put the transaction details in the blocks that they have mined for them to go through.
So suppose Alice wants to send 4 BTC to Bob, she will send this transaction data to the miners, the miner will then put it in their block and the transaction will be deemed complete.
Seems pretty straightforward right? However, this is where we face another problem.
As Bitcoin becomes more and more popular, this becomes more time-consuming. Also, there is another issue that one should take note of, transaction fees. When miners mine a block, they quite literally become temporary dictators of that block. In return for putting transactions in them, they charge a “toll” called transaction fees.
The higher the transaction fees that you pay, the faster your transaction will get processed by the miners. This may not be the best proposition for people who don’t have a high supply of bitcoins. In fact, check out this graph:
If you pay the lowest possible transaction fees, then you will have to wait for a median time of 13 mins for your transaction to go through.
Also, remember another thing. Bitcoin and Ethereum need to account for block production time as well. Bitcoin has a block production time of 10 mins while Ethereum does it in 15 seconds. So, more often than not, one may actually have to wait for the block to be mined for their transaction to go through.
There is another thing that hinders the number of transactions that the blocks can actually hold, and that is the block size. Bitcoin, as we have mentioned above, has a 1 MB block size which limits its transaction carrying capacity.
Ethereum doesn’t have a “defined” block size and a new block gets mined every 15 seconds. So it must be doing pretty well right? Unfortunately, that doesn’t seem to be the case.
Each and every block in Ethereum is limited by a gas limit of 6,700,000 and each transaction costs 21,000 gas, you can see that there is a limit here as well.
So, one debate that has raged on in Bitcoin is, why not simply raise the block size? Well, this is where we come to the issue that has divided the Bitcoin community into two.
To Increase or Not To Increase
We will try to take a neutral stance here. Let’s see what both the sides have to say.
Against Block Size Increase
Let’s look at some of the arguments that people have had against block size increase.
- As increased block-size means more transactions can be easily inserted, it will decrease the average transaction fees. This will give miners absolutely no incentive to carry on in the network and they may move on to other projects. Now, this is bad because of a number of reasons.The overall strength and security of the network is directly proportional to the overall hashrate. Higher the hashrate, the faster the network can solve cryptographic puzzles. Now, if the miners start leaving, the overall hashrate will decrease which will greatly reduce its overall network security.Also, as the number of miners decreases, it increases the chance of launching a 51% attack on the network.
- There is also this entire group of Bitcoin community who believes that Bitcoin is far too important to be used for simple activities such as daily transactions. They equate Bitcoin to gold. Gold is used for storing value, however, you don’t really transact with gold anymore, do you? These people believe that Bitcoin has a far higher purpose than just being regular everyday currency.
- A block size increase can only happen after a hard fork in the system. If that happens the entire Bitcoin ecosystem will split in two and we will have the same situation that happened with Ethereum when they split into Ethereum and Ethereum Classic.
- With an increased block size, the size of the entire network will increase proportionally as well. As a result, the amount of processing power required to mine will increase too. Because of this, all the small mining pools that are existing in the market will be taken out.How do you think that will affect the market?The large mining pools, who already have a huge share in the market will see their shares increasing even more. What this does it that it increases the centralization of the market.
- Even though “team block size increase” wants to achieve scalability by increasing block size, the problem is that it will only lead to linear scalability instead of exponential scalability. What do we mean by that?The current throughput of Bitcoin is 7 transactions per second. If we increase the block size X times, then the new throughout will only be 7X transactions per second. According to them, this is not a good long-term solution.
For Block Size Increase
Let’s look at some of the arguments that people have had for the block size increase.
- Increasing block size actually works to the miner’s benefit. Think about it, since the number of transactions inside each block will increase, the overall transaction fees that a miner can actually collect from their mined blocks will increase. Even if the transaction fee collected per block goes down.
- Bitcoin was meant to be the money of the people. The whole idea was for everyone to become their own bank and engage in transactions without dealing with a third party like banks. If the block size doesn’t change then there is a very real possibility that the transactions fees will go higher and higher. When that happens, the common man will never be able to use it and it will be used exclusively only by the rich and big corporations.
- Another misconception that team “anti block size” has, at least according to the supporters, is that they feel that too much change is going to be happening at the same time. According to the supporters, the change is going to be pretty steady and won’t cause major disruption right off the bat.
- Support for block size increase has gained a lot of traction over time. It is no longer a mere minority who are behind this proposal.
The biggest point that team anti-block size has is that a block size increase will inevitably lead to a hard fork which should be avoided at all costs. After all, the strength of a coin is directly proportional to the strength of its community. It makes no sense to simply split the community in half.
This is why, before we continue, it is important that you know what forking means.
What is a Fork?
Most people see a fork as being an eating utensil, an alternative to eating with chopsticks or with your fingers. There is another sense of the word, as in a divergence in a path. A fork in the road or a fork in the river indicate that a choice must be made to proceed; should one go left or should one go right?
With blockchains, the same is true. In the simplest terms, a crypto fork is a disagreement, permanently etched in code. It represents a fight where the token or coin failed to reach consensus, and as a result, the two sides opted to act instead of “talk it out.”
A fork is what happens when the system breaks down, either intentionally or incidentally.
To understand this, one must look at how blockchains work. A blockchain is a connected series of cryptographically-encoded records. These records form a chain based on a Merkle tree where every successive block contains the encoded hash of the previous block. The consensus protocol determines which block rightfully is the successor.
A common misunderstanding with blockchains is that only one block is connected to the chain per link. The truth is that many blocks connet to the chain at each level, and each of these blocks have blocks that link to them. As mining is a competitive activity, there are many “runners-up.” As the connector to the chain is included in the new block itself, each of these blocks “connect” to the chain.
It is up to the consensus protocol to determine which of these blocks is the “official” one. The remainder – orphans – are treated differently depending on the blockchain. For bitcoin, for example, the “orphans” – or “stales” – with inferior proofs-of-work are ignored. “Orphans” in Ethereum – called “uncles” – however, are used to help improve transaction times and still receive mining rewards despite not being “official.”
“Orphans” can also be the results of a failed attempt seize control of the blockchain.
However, when the consensus protocol disagrees which block is the “official” one, forks happen. This can be because of a disagreement in a change of protocol, or because of an intentional software shift, or by malicious means. Despite the means, two “official” blocks are named. This creates two new branches, with “official” blocks being named by that branch’s version of the consensus protocol. Each of these branches can be considered a separate blockchain – depending on if the fork is “hard” or “soft” – with both sharing the blocks before the protocol change. All bitcoin clones, for example, share bitcoin’s “genesis block” as the first block of their respective blockchains.
With bitcoin, for example, there have been six forks:
- August 2015: Bitcoin Core (the network’s operating software) forked with Bitcoin XT over disagreements about block size,
- February 2016: Bitcoin Core forked with Bitcoin Classic over disagreements about block size,
- May 2017: Bitcoin Core forked with Bitcoin Unlimited over disagreements about block size;
- August 2017: Bitcoin blockchain (due to blockchain code change and not a consensus software change) forked with Bitcoin Cash over disagreements about block size,
- October 2017: Bitcoin blockchain forked with Bitcoin Gold over proposed switch from Application-Specific Integrated Circuits (ASICs) for mining to Graphics Processing Units (GPUs), and
- February 2018: Bitcoin blockchain forked with Bitcoin Private over should users be able to cloak transaction metadata.
- There are “lesser” forks or intentional deviations of the Bitcoin Core software – as Bitcoin Core is open-source – to create a new coin. This includes Litecoin and Dogecoin (which is a fork of Luckycoin, which is a fork of Litecoin). Most bitcoin derivatives, however, involve new implementations of the respective blockchains.
There are four types of forks: hard forks, soft forks, software forks (permanent and temporary), and a user-activated soft fork.
The most common type of fork is a hard fork. Per Investopedia, “A hard fork (or sometimes hardfork), as it relates to blockchain technology, is a radical change to the protocol that makes previously invalid blocks/transactions valid (or vice-versa). This requires all nodes or users to upgrade to the latest version of the protocol software. Put differently, a hard fork is a permanent divergence from the previous version of the blockchain, and nodes running previous versions will no longer be accepted by the newest version. This essentially creates a fork in the blockchain: one path follows the new, upgraded blockchain, and the other path continues along the old path. Generally, after a short period of time, those on the old chain will realize that their version of the blockchain is outdated or irrelevant and quickly upgrade to the latest version.”
The most infamous hard fork is the Ethereum Classic fork. The fork involved the contentious decision to restore Ethers stolen from the DAO, a venture capital fund-running decentralized autonomous organization. “The DAO’ is the name of a particular DAO, conceived of and programmed by the team behind German startup Slock.it – a company building ‘smart locks’ that let people share their things (cars, boats, apartments) in a decentralized version of Airbnb,” blockchain strategist David Siegel wrote in an editorial. “The DAO launched on 30th April, 2016, with a 28-day funding window. For whatever reason, The DAO was popular, raising over $100m by 15th May, and by the end of the funding period, The DAO was the largest crowdfunding in history, having raised over $150m from more than 11,000 enthusiastic members. The DAO raised far more money than its creators expected. It can be said that the marketing was better than the execution, for during the crowdsale, several people expressed concerns that the code was vulnerable to attack.”
“Unfortunately, while programmers were working on fixing this and other problems, an unknown attacker began using this approach to start draining The DAO of ether collected from the sale of its tokens. By Saturday, 18th June, the attacker managed to drain more than 3.6m ether into a ‘child DAO’ hat has the same structure as The DAO. The price of ether dropped from over $20 to under $13. Several people made attempts to split The DAO to prevent more ether from being taken, but they couldn’t get the votes necessary in such a short time. Because the designers didn’t expect this much money, all the ether was in a single address (bad idea), and we believe the attacker stopped voluntarily after hearing about the fork proposal.”
The decision to restore the ethers violate a key tenet of cryptocurrency: that the code is law and actions needed to correct “lawful” actions, per the consensus protocol, should be avoided. By taking an action more than the consensus protocol, the rules of the game are being changed mid-game, opposition to the move argued. When the blockchain was changed to reverse the transaction. A vocal minority (about three percent of the community) continued to follow the original blockchain, forming Ethereum Classic.
There is no way to bring back together Ethereum and Ethereum Classic. Additionally, a user cannot negotiate between the two blockchains with the same token – the original Ethereum token split along with the blockchain. A hard fork always results in a new token and a new blockchain – even if the two blockchains share the same blocks before the split.
In the case of the DAO hack, on the original blockchain, the tokens were not restored, and the hack was considered an unethical, but legal transfer. The stolen ethers were not exchanged to ETC. The new Ethereum blockchain invalidated the transactions, restoring the tokens to their original owners.
Conversely, a reversible fork is called a “soft fork.” “In terms of blockchain technology, a soft fork (or sometimes softfork) is a change to the software protocol where only previously valid blocks/transactions are made invalid,” per Investopedia. “Since old nodes will recognize the new blocks as valid, a softfork is backward-compatible. This kind of fork requires only a majority of the miners upgrading to enforce the new rules, as opposed to a hard fork which requires all nodes to upgrade and agree on the new version.”
Unlike a hard fork, which rejects nodes that choose not to follow the consensus protocol change, a soft fork only compromises the nodes. “New transaction types can often be added as soft forks, requiring only that the participants (e.g. sender and receiver) and miners understand the new transaction type. This is done by having the new transaction appear to older clients as a “pay-to-anybody” transaction (of a special form), and getting the miners to agree to reject blocks including these transactions unless the transaction validates under the new rules. This is how pay to script hash (P2SH) was added to Bitcoin.”
The way to think about a soft node is like this: a cryptocurrency issues a new protocol rule. The individual node can opt to not follow the new rule – either intentionally or due to ignorance. If that node opts not to follow the new rule, its blocks are automatically made stale and transactions verified by it are rejected by the consensus. As stated previously, this does not stop the node’s blocks from being accepted according to the old protocol and forming a new chain. Once the node adopts the rule, however, its blocks will be recognized by the new consensus and the node’s “rebel chain” will be abandoned.
The DAO hack could have been solved by a soft fork, invalidating the affected tokens. Doing so, however, would create a worse security loophole.
Andreas Antonopoulos describes the difference between hard and soft fork like this:
“If a vegetarian restaurant would choose to add pork to their menu it would be considered to be a hard fork. if they would decide to add vegan dishes, everyone who is vegetarian could still eat vegan, you don’t have to be vegan to eat there, you could still be vegetarian to eat there and meat eaters could eat there too so that’s a soft fork.”
Software forks – also known as a “git fork” – are intentional deviations from the consensus protocol and the operating software to develop new protocols and software or to test changes to the existing protocol. These can be temporary, as in protocol changes to the existing blockchain, or permanent, as in the development of a new blockchain.
Software forks are always suggestions. Developers cannot mandate a software fork to be embraced as changes to the consensus protocol. Software forks can be adopted or rejected at the community’s discretion.
Ethereum, for example, started as a software fork of bitcoin before permanently separating itself. It would return to bitcoin as the first ICO.
User-Activated Soft Forks
The most controversial type of fork is a user-activated soft fork, where a soft fork is pushed through without majority approval of the mining nodes, who are responsible for transaction verification. Instead, the fork seeks the approval of the consensus of full nodes. These nodes must represent an economic majority on the network.
In fact, we will talk more about user-activated soft fork when we talk about SegWit.
Bitcoin Forks Prior to Bitcoin Cash
Several Instances of increasing the block size and forking away from the main Bitcoin blockchain was implemented before Bitcoin Cash. Let’s look at some of these forks. Keep in mind, we are only talking about Bitcoin forks which have a block size larger than 1 MB. This is the reason why we won’t be bringing up Bitcoin Gold and Bitcoin Private.
#1 Bitcoin XT
Bitcoin XT was the first notable fork of the bitcoin protocol and faced widespread media coverage. The movement was spearheaded by Mike Hearn who launched the software in late 2014 to include some of the changes that he was proposing to Bitcoin Core. This proposal was called the Bitcoin Improvement Proposal (BIP 64). It called for the addition of “a small P2P protocol extension that performs UTXO lookups given a set of outpoints.”
His main aim for this fork was to increase the throughput from 7/ sec to 24/sec. This is how he did that:
- Increase the block size from 1 MB to 8 MB
- Including a mechanism which doubles the block size every 2 years.
The XT fork would have been fully activated once 75% of the miners gave their approval for the changes. It gained an immense amount of interest in the early stages as more than 1000 nodes ran its software in the late summer of 2015 however interest soon began to drop as the 75% threshold was not achieved by early 2016, the earliest possible switchover date.
#2 Bitcoin Classic
After the XT failure, a lot of sympathizers believed that a block size increase was still the correct way to go forward. This is when Bitcoin Classic came about, and its main aim was to increase the block size from 1mb to 2mb as opposed to 8mb.
Like XT, Classic saw initial interest with about 2000 nodes using the software, however, the number fell dramatically over time.
On November 10, 2017, Bitcoin Classic ceased operations and declared that “Bitcoin Cash is now the only hope for bitcoin to become scalable.”
#3 Bitcoin Unlimited(BU)
There is a lot of similarities between XT, Classic and Bitcoin Unlimited. Like those two, Unlimited is also a fork of Bitcoin Core, however unlike them, it doesn’t have a set block limit, hence the name “Bitcoin Unlimited”. Bitcoin Unlimited grants their users the power to choose whatever block size they want to go with. The limit that achieves the majority consensus in the network would be the new block size limit.
The most notable Bitcoin Unlimited supporters were Roger Ver, Antpool, bitcoin.com, BTC.TOP, GBMiners, and ViaBTC among others.
Bitcoin Unlimited has had some super bumpy moments in its journey thus far:
- On February 2, 2017, a bug in the BU caused Bitcoin.com to mine an invalid block
- A bug which attacked the network caused the overall BU nodes to fall from 780 to 370 on 14th March 2017
- On 24th April 2017, memory leaks crashed 70% of the nodes in BU
- Again on 8th May, 70% BU nodes went offline. According to developer Andrea Suisani, this happened because of an Xthin protocol
Bitcoin Unlimited developers still maintain an edition of their software which works on Bitcoin Cash called “BU Cash.”
All this brings us to the most successful “big block hard fork” yet. Bitcoin Cash.
What is Bitcoin Cash?
According to their website: “Bitcoin Cash is peer-to-peer electronic cash for the Internet. It is fully decentralized, with no central bank and requires no trusted third parties to operate.”
So, why “cash”? Because they are laying emphasis on Bitcoin Cash’s primary motivation of being a “peer-to-peer electronic cash” to carry out more transactions.
What are the features of Bitcoin Cash that makes it different from Bitcoin?
- The block size will be 8 MB.
- It won’t have segwit which has been incorporated by Bitcoin Core.
- It won’t have the “replace by fee” feature
- It will have replay and wipeout protection.
- It offers a way to adjust the proof-of-work difficulty quicker than the normal 2016 block difficulty adjustment interval found in Bitcoin.
So, let’s look at how Bitcoin Cash works and how it came to be.
UAHF and Bitcoin Cash
Bitmain, the company behind Antpool which happens to be one of the biggest mining pools in the world, proposed a user activated hard fork to create Bitcoin Cash. Because it is a hard fork, Bitcoin cash won’t be backward compatible with the rest of the bitcoin blockchain. Also, a hard fork doesn’t require a majority support from the entire network to be activated. Whoever is interested can simply fork out from the Bitcoin Core protocol regardless of how much support they get.
At the “Future of Bitcoin” conference a developer named Amaury Séchet revealed the Bitcoin ABC (Adjustable Blocksize Cap) project and announced the upcoming hardfork. Following the announcement, and after Bitcoin ABC’s first client release, the project “Bitcoin Cash” (BCH) was announced which came into full effect on August 1, 2017.
How Does Bitcoin Cash Fight Replay Attacks?
So, before we understand how Bitcoin Cash stops replay attacks, let’s understand what it actually means.
To put it simply, a replay attack is data transmission that is maliciously repeated or delayed. In the context of a blockchain, it is taking a transaction that happens in one blockchain and maliciously repeating it in another blockchain. Eg. Alice is sending 2 BTC to Bob, under a replay attack she will send him 2 BCH as well, even though she never meant to do that.
So, how does Bitcoin cash prevent replay attacks?
Using a redefined sighash algorithm. This sighash algorithm is only used when the sighash flag has bit 6 set. These transactions would be invalid on the non-UAHF chain as the different sighashing algorithm will result in invalid transactions.
Using OP_RETURN output which has the string “Bitcoin: A Peer-to-Peer Electronic Cash System” as data. Any transaction which contains this string will be considered invalid by bitcoin cash nodes until the 530,000th block. Basically, before that block, you can split your coins by transacting on the non-UAHF chain first with the OP_RETURN output, and then transacting on the UAHF chain second.
What is Replace by Fee?
What do we mean by “replace by fee”? It is actually a feature that is available in Bitcoin. Consider this scenario. Suppose you want to send 2 BTC to your friend but the transaction simply isn’t going through because of the backlog in the system?
Now, you can’t delete this transaction, because the blockchain architecture doesn’t allow that. Blockchain transactions are non-tamperable so you can’t do that. What you can do, however, is just increase the transaction fees that you are giving away with your transaction. So, if you send another 2 BTC with a higher transaction fee, the miners will put this new transaction into the block and overwrite the previous one, making it null and void.
While the “replace-by-fee” system is profitable for the miners, it is pretty inconvenient for users who may not be that well to do. Bitcoin Cash wants to do away with this system because they want to be as accessible to the common man as possible.
How Bitcoin Cash Attracted Miners
MIners are really important for the overall growth and functioning of the crypto ecosystem. So, how did Bitcoin Cash get so many miners to join their network? Well, turns out that Bitcoin cash has a set rule as to when it decreases its difficulty.
Median Time Past or MTP is the median of the last 11 blocks that have been mined in a blockchain. Basically, line up the last 11 blocks one after another and the time at which the middle block is mined is the median time past of the set. The MTP helps us determine the time at which future blocks can be mined as well. Here is a chart of the MTP of various blocks after it launched:
So, how does the difficulty adjustment in Bitcoin Cash works? If the Median Time Past of the current block and the Median Time Past of 6 blocks before is greater than 12 hours then the difficulty reduces by 20% i.e. it becomes 20% easier for miners to find newer blocks. This gives the miners some power to adjust difficulty, eg. check out the 13-hour gap between blocks 478570 and 478571. The miners may have simply been doing this to make the blocks easier to mine.
There is another thing that you should know when it comes to difficulty rate can adjustment in a cryptocurrency. It adjusts according to the number of miners in the ecosystem. Basically, if the total number of miners goes down, then the overall hashing power of the system goes down. This is what happened when Bitcoin Cash first started out:
- They were struggling to get miners
- The difficulty of the system dropped down
- This attracted a lot of miners which made this extremely lucrative.
- In fact, the influx was so hight that the hashing power of BTC actually halved for a bit which decreased overall transaction time and increased the transaction fees.
Ok, now that we have seen all the forks, let’s look into SegWit.
So, finally, we come to SegWit. SegWit stands for Segregated Witness and we will look into what we mean by that in a bit. SegWit came about as a result of a User-Activated Soft Forks. This UASF pushed through the P2SH soft form for bitcoin (BIP16, the Pay to Script Hash). This was proposed to push through SegWit via BIP148.
“BIP148 is a UASF that is designed to cause the existing SegWit [Miner Activated Soft Fork] deployment to cause activation in all existing SegWit capable node software (which currently is 80% of the network nodes),” reads the UASF website. “How does BIP148 Work? From August 1st, 2017, miners are required to signal readiness for SegWit by creating blocks with the version bit 1. This will cause all SegWit ready nodes, which make up over 80% of the network, to activate and begin enforcement. “
“BIP148 requires support from the economic majority, particularly exchanges and wallets. If this does not occur, node software supporting BIP148 should not be run after August 1st as it will cause a chain split leading to the abandonment of BIP148. There are strong economic incentives in the Bitcoin system for nodes to cooperate and remain in consensus to prevent chain splits. If the economic majority is signalling as of August 1st, miners have many incentives to follow along. Not following along would make it difficult to sell coins mined after August 1st as the blocks would not be accepted by the economic majority. Essentially, miners would be producing an altcoin not recognized by users and exchanges, making them less useful and in lower demand.”
“Some miners could opt to ignore the BIP148 rule and attempt to split the chain, but this would require a majority of miners who would be out of consensus from the rest of the economic majority. If a majority of hash power follows BIP148, all nodes will follow the chain regardless of if they are running BIP148. Non-compliant blocks will be orphaned. All SegWit nodes will eventually activate SegWit. If a minority of the hash power (under 51%) follows BIP148, nodes running BIP148 will be fine, but those not running BIP148 will be out of consensus with the rest of the economy. In this scenario, the more of the economy that runs BIP148, the better. Miners will find it difficult to sell their coins leading economically motivated miners to start enforcing BIP148.”
Ok, so now we know about the background, let’s look into the details.
Inputs and Outputs in Bitcoin
How does a transaction in Bitcoin actually work? There are two sides to a transaction:
Let’s look at how the dynamics of a simple transaction works:
Consider this situation. You have $50 in your pocket, you go to the thrift store and buy something for $20. You pay that with the $50 note and then you get back $30 in change. Now suppose you have to go to the grocery shop, what are you going to use to pay for your expenses? The change that you received from your previous transaction (aka the $30 change from the thrift store) right?
That is exactly how Bitcoin transaction works.
Your transaction inputs consist of change from your previous Bitcoin transactions. These are called UTXO or Unspent Transaction Outputs. So suppose the change transactions or your UTXOs are called TX(0), TX(1) and TX(2). In order to form the input for your new transaction input, you will need all of them. This is what it will look like:Now, let’s look at the output side.
The output part of the transaction consists of the amount of money which you want to give to your friend (TX(OUTPUT) in this case) and the leftover change that you can use as inputs for your future transactions.
- The input transaction has to be greater than the output transaction, because you will need to account for transaction fees as well. In other words, Transaction fees = TX(Input) – (TX(output) + Change)
- If you don’t have the necessary amount UTXOs required to fulfil your inputs, then your transaction will get rejected
- Your friend also needs to show that they can provide the proof required to get the bitcoins that you are sending them. You will send the bitcoins to their public address and they can only unlock it via their private key.
- Before they even do that, you need to validate that it is actually you who is sending the bitcoins in the first place. The way you do that is by signing off your transactions with your digital signature. This digital signature is called “signature data” and it will be extremely important later on in our understanding of segwit.
Transactions: Behind The Scenes
Let’s go a wee bit deeper.
Let’s look at the Bitcoin script behind these transactions. Keep in mind that we have taken the code from Andreas M. Antonopoulos. “Mastering Bitcoin.”
First up, let’s look at the transaction output.
Every single transaction output has two parts when you look at the code:
- The output transaction, how much Bitcoin you are sending
- The locking script called the scriptPubKey which your friend will need to unlock with their private key to gain access to the coins.
Let’s look at the code:
“scriptPubKey”: “OP_DUP OP_HASH160 ab68025513c3dbd2f7b92a94e0581f5d50f654e7 OP_EQUALVERIFY OP_CHECKSIG”
“scriptPubKey”: “OP_DUP OP_HASH160 7f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a8 OP_EQUALVERIFY OP_CHECKSIG”,
In the code above, we have two outputs”
- One output has a value of 0.015 BTC
- The second output has a value of 0.0845 BTC
In the code above, the locking script which is required to be unlocked for your friend to get their hands on the 0.015 BTC output is: “scriptPubKey”: “OP_DUP OP_HASH160 ab68025513c3dbd2f7b92a94e0581f5d50f654e7 OP_EQUALVERIFY OP_CHECKSIG”
Now let’s take a look at transaction inputs.
In order to do an Input, your wallet will go through your UTXO’s and will select the ones which will have enough value to cover the expenses. Think about the example we have just given. If you are sending your friend 0.15 BTC and your UTXO set looks like this:
UTXO a = 0.07 BTC
UTXO b = 0.2 BTC
UTXO c = 0.001 BTC
Your wallet will automatically choose UTXO a and UTXO b to cover the transaction. The UTXO c which is left over will become your UTXO for another transaction
Alright, let’s look at the code now:
“scriptSig” : “3045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813[ALL] 0484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adf”,
Alright, let’s see what is happening right now:
- txid: This is transaction ID which refers to the transaction from which the UTXO has been generated. This will let you keep track of the transaction.
- vout: This pinpoints to which output from the transaction we are using. So, if that transaction had two UTXOs the first one will be labelled 0and the second one will be labelled 1. In this case we are using the first UTXO i.e.UTXO 0.
- scriptSig: This is the digital signature which
- sequence: This helps users update their transactions before they are confirmed and finalized in the the blockchain.
Alright, now we want you to take a look at scriptSig again:
“scriptSig” : “3045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813[ALL] 0484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adf”
You see how bulky that data is?
We have already mentioned that the blocks have a 1 MB limit. The scriptSig itself takes up around 60% of the space even though it is only useful for beginning part of the transaction when the sender has to validate their signature.
Ok, so now that we understand what transaction works like, let’s get to the next which we need to understand to get what sidechains mean.
What are Sidechains?
The concept of sidechains have existed for quite some time now. The idea is to simply have a blockchain which runs in parallel to the main blockchain. It enables users to move tokens and other digital assets from the main blockchain to the sidechain and vice-versa.
So, how exactly does this happen? Let’s find out:
- The sidechain is attached to the parent chain via a 2-way peg.
- The two-way peg allows the movement of assets, at a predetermined rate, between the parent chain and the sidechain.
Back in 2012, people began to understand that the bulky signature data is problematic and needs to be dealt with. People tried to play with the idea of taking signature data away from the transactions. Participants like Russell O’Connor, Gregory Maxwell, Luke Dashjr and Dr. Adam Back were working on a way to make this work, however, they hit a wall. The only way that would have been possible was to do some proper change in the Bitcoin blockchain, which would end in a hard fork, something that they wanted to avoid in the first place.
A light in the tunnel appeared in 2015 when Blockstream’s Dr. Peter Wiulle came up with an ingenious solution. Blockstream was already working on a sidechain for Bitcoin. Dr. Wiulle thought, why not add the signature data to this sidechain. This would certainly prove a very elegant solution of the signature data quandary by separating it from the main chain. This is what would eventually become SegWit and this is how it would look like:
By removing the signature data they achieved two things:
- Made more block space
- Made transaction malleable free and made light network implementation much easier (more on this in a bit)
However, they were still floored by the hard fork problem. SegWit in this state still required a hardfork. This was when developer Luke Dashir came up with two brilliant solutions which would lead to a segwit soft fork.
- Firstly, to keep the signature data in the side chain as a Merkle Tree,
- Keep the Merkle root of the signature data in the blocks.
Now, we go on the next chapter. What are Merkle Trees?
What are Merkle Trees?
Check this diagram out:
This what a Merkle Tree looks like.
The Merkle tree in the diagram above has 4 levels. Level 1, the top hash, is known as the root node because the entire tree is sprouting from it. The level 4 has all the leave nodes: L1, L2, L3, and L4.
Each and every node in the higher level becomes the child of the nodes in the preceding level. So, the nodes of Level 4 are the children of Level 3 who in turn become the children of Level 2. Similarly, level 2 nodes become the parent nodes of Level 3, and Level 3 nodes become the parent nodes of Level 4.
Ok, so that is all well and good, but how does a Merkle Tree help with blockchain?
Think about the sheer amount of transactions that each block holds in the blockchain. A block in the Bitcoin blockchain holds around 500 transactions. Now if were to just stuff all this data inside the block, it will be extremely untidy and the data will be super disorganized. Also, if someone were to track back and go through the transactions inside a block, it will be extremely tedious. Using a Merkle tree helps us greatly cut down on the time required to zero in on a particular transaction.
What do we mean by that?
Here is what a typical Merkle Tree inside a blockchain looks like:
So, if we want to zero in on a particular on a particular data without going through them one after another?
Well, you simply track it down through its parents! Kinda like this:
Doing this significantly decreases the time it would have taken you.
Alright, so now we know how Merkle Trees work. Back to SegWit.
SegWit Become Soft Fork
Segwit developers wanted to run a Merkle Tree with the signature data. After that, they needed to put the Merkle root of the signature data inside the block itself to make sure that segwit is a soft fork. They decided to put the root in the coinbase transaction spot. The coinbase transaction is the first transaction that takes place in a block, this basically the transaction that gives miners their reward and has no input value at all.
However, by doing so, the developers did something else that wasn’t intentional at all. By putting the signature Merkle root in that spot, they somehow ended up increasing the blocksize without actually trying to in the first place. So, SegWit somehow achieved increasing the block size limit while keeping the whole transition as a part of soft fork. This was a humongous breakthrough.
So, in 2015 Dr Wiulle introduced the SegWit proposal to the HongKong convention and its reception was polarizing, to say the least. This was supposed to be the soft fork scalability solution that everyone was looking for, however, not many people jumped on board with the idea.
Some of the miners had a big problem with SegWit. You see, then SegWit developers added a special clause to their code which stated that a 95% super approval from the miners was essential for it to go through. This was put in place because miners are an essential cog in the system and getting near unanimous approval from them was important. However, as it turned out, most miners didn’t even want to activate segwit in the first place because the increased block size will increase the number of transactions and decrease the transaction fees that they could possibly collect. Also, it will completely negate “replace by fee”.
Along with the miners, several developers weren’t particularly happy with the segwit solution. According to them, segwit was a simple hack which gave a temporary solution. This, in turn, frustrated the normal users who wanted segwit to be activated and, as a result, get faster transactions.
The CEO of DCG Barry Silbert believed that this could be a pivotal moment which may rip apart the bitcoin community. As a result, he called in everyone for a truce meeting in New York. The outcome of this meeting is what is known as “The New York Agreement”.
On 21st May 2017, important members of the Bitcoin community came to New York for the convention. Ultimately, a compromise was reached between the pro-segwit and the pro-blocksize increase camp. The conclusion and outcome of the meeting is called “The New York Agreement” or Segwit2x. The outcome has the following conclusions:
- Segwit needs to go up and running. The percentage of consenting miners went down from 95% to 80%. After the soft fork, any miner who mines non segwit friendly block will be automatically removed from the blockchain. Miners who showed their support to this started including the letters “NYA” in their blocks.
- After Segwit activation, there will be a hardfork which will increase the block size from 1 MB to 2 MB.
After the Meeting
First, let’s deal with the community reaction of Segwit2X.
There were some extremely vocal detractors to Segwit2x. In fact, the dissension was so loud that many people forked off from Bitcoin and gave birth to Bitcoin Cash. On November 8, 2017, Mike Belshe, the Bitgo CEO published a post which announced that the SegWit 2X will unfortunately not be taking place because of lack of community support.
As Belshe states, “the Segwit2x effort began in May with a simple purpose: to increase the blocksize and improve Bitcoin scalability. At the time, the Bitcoin community was in crisis after nearly 3 years of heavy debate, and consensus for Segwit seemed like a distant mirage with only 30% support among miners.” Belshe adds that “Segwit2x found its first success in August, as it broke the deadlock and quickly led to Segwit’s successful activation.
Our goal has always been a smooth upgrade for Bitcoin. Although we strongly believe in the need for a larger blocksize, there is something we believe is even more important: keeping the community together.” Belshe concedes “it is clear that we have not built sufficient consensus for a clean blocksize upgrade at this time. Continuing on the current path could divide the community and be a setback to Bitcoin’s growth. This was never the goal of Segwit2x.”
Alright, now on to Segwit.
A lot of members in the community agrees to go forward with segwit. The activation was supposed to happen around mid-July, unfortunately, because of multiple reasons, the miners missed that window.
This error caused huge panic in the group and BTC’s price went down from $2500 to $1900. This drop in price kickstarted the mining community into action. By 20th July, the first stage of segwit activation, the BIP 91 activation was locked in. By August 8th the point of no return was reached and finally, on August 24th, Segwit got activated.
How SegWit Helps With Scalability
Let’s assume that witness data makes up 54% of the transaction space. So Segwit transactions should take up 41% less blockweight that old style transactions. Let’s look at the following formula:
So, according to the formula, if we assume that transaction fees level remains the same, by upgrading to Segwit, the users should pay 41% lower fees than before.
The chart below (by BitMex) compares how block weight and block size could vary as the amount of witness data (signature data) in a block increases.
The chart goes from low levels of segwit adoption to higher adoption rates. So, as we can see, in high adoption rates, the blocksize maybe around 2MB and consist of 1.3 MB of witness data and 0.7 MB of non-witness data. The block weight also will be somewhere around 4 million units. This increases the overall network throughput by around 100%.
The Month After SegWit Activation
The chart above shows how Segwit adoption has increased steadily in its first month. Adoption reached 4.5% of the transactions. All graphs from BitMex.
How SegWit Helped Lightning Transactions
The most immense way that SegWit has helped Bitcoin’s scalability is by allowing the creation of the lightning network.
First, let’s go through what Lightning Network does.
The lightning network, conceptualized by Joseph Poon and Tadge Dryja, has been long touted as the solution to all of Bitcoin’s scalability issues, and Litecoin has been one of the many projects that are working on it. So what is the lightning network? Let’s give you a brief overview first.
Two people, let’s say, Alice and Charlie, open a state channel between them and exchange as many coins as they want between them OFF THE BLOCKCHAIN. When they are done making the transfers, the final state of the transaction is put on the main blockchain.
Before we start, let’s understand what state channels mean. A state channel is a two-way communication channel between participants which enables them to conduct interactions, which would normally occur on the blockchain, off the blockchain. So, what this eventually does is that it exponentially reduces the time taken for a transaction to go through.
Can you guess why?
When you create a state-channel between two parties. they can engage in an infinite (theoretically speaking) number of microtransactions between themselves without interacting with a blockchain. Since everything is happening off-chain, the miners only need to put the final state of the channel into the blockchain.
So what are the requirements to do an off-chain state channel?
A section of the blockchain state is locked up via multi-signature or some sort of a smart contract and it is agreed upon by a set of participants. These participants interact with each other without submitting any data to the miners. As we have stated earlier, the final state is presented to the miners and added to the blockchain.
The state channels can be closed at a point which is predetermined by the participants via one of the following methods:
- Either the participants can agree beforehand to close the state channel after a given amount of time has lapsed.
- Or, it could be based on the total amount of transactions done eg. close the chain after $1000 worth of transactions have taken place.
State channels are useful in many applications, where they are a strict improvement over doing operations on-chain. Having said that, they are not without their limitations. Let’s look at some of the features and limitation of state channels.
- State Channels are reliant on availability. So, if Alice is taking part in a state channel and she loses her internet connection at that very moment, she might not be able to upheld her role in the channel. Having said that, it could be possible for her to pay someone to maintain availability on her behalf.
- State channels are the most useful when participants are going to be exchanging many state updates over a long period of time.
- State channels are best used for applications with a defined set of participants.
- State channels have extremely high-quality privacy properties because everything is happening “inside” a channel between participants, rather than broadcast publicly and recorded on-chain. Only the opening and closing transactions must be public.
- State channels have instant finality, meaning that as soon as both parties sign a state update, it can be considered final. Both parties have a very high guarantee that, if necessary, they can “enforce” that state on-chain.
Payment channels are a form of state channels that deals only with payments.
Hashed timelock contracts or “HTLCs” are one of the most convenient applications of the payment channels. In fact, the Lightning Protocol is an implementation of the HTLC. So, what is an HTLC? Till now we have seen channels which use “timelocks”. An HTLC “extends” that by introducing “Hashlocks” along with the timelocks.
Because of HTLC, one can open payment channels off the Bitcoin blockchain where parties can agree upon a preset deadline and then engage in innumerable microtransactions. The payments are also acknowledged between parties via the submission of cryptographic proofs. Along with these, HTLCs have two major advantages:
- Firstly, it allows for cross channel transactions.
- Secondly, it allows the parties to forfeit the payment given to them and return it to the payer.
Plus, there is another amazing feature that comes in thanks to the HTLC. It makes cross chain transactions possible. This is called atomic cross chain trading and enables users to exchange a part of cryptocurrency on one chain (eg. bitcoin on the main blockchain) for a part of cryptocurrency on another chain (bitcoin on a side chain).
Ok, now let’s go into the details.
The lightning network, as we have mentioned before, is based on HTLCs aka Hashed Timelock Contracts. Let’s see how it works. Imagine Alice wants to send some bitcoins to Charlie, and they both have Bob in common.
- Alice opens a channel with Bob and Bob opens a channel with Charlie.
- Alice declares that she wants to pay Charlie 0.01 BTC.
- Charlie declares a random string S and generates its hash H and hands it to Alice.
- Alice sends Bob the hash H and they open a multi-sig channel between them. The conditions of the channel are:
a) Bob gets the 0.1BTC if and only if he can show Alice the string S from which the H is derived.
b) There is a nLocktime of 2 days wherein, if Bob cannot produce the string then Alice gets a refund of 0.01 BTC.
- Bob then shows the hash H to Charlie, proving that he has interacted with Alice and they proceed to open a multi-sig channel between them with the following conditions:
a) Charlie gets 0.01 BTC if and only he shows Bob the String S from which the hash H has been derived.
b) There is a nLocktime of 1 day (less than the locktime of the Bob-Alice channel) wherein if Charlie can’t produce the string then Bob gets a refund of 0.01BTC.
- If Charlie produces the string S then Bob sends him the 0.01BTC.
- Similarly, Bob shows Alice the string S and gets the 0.01BTC from her.
Ok, so that’s what the lightning network is. Now let’s look into how SegWit helps us here.
SegWit and Transaction Malleability
One of the most important elements of the cryptocurrency model is hashing. A hashing function can take in any input of any length but the output it gives is always of a fixed length. A hashing function has multiple properties, including the snowball property.
Let us show you what we mean by that. For this example, we will be using the SHA-256 hashing algorithm, which incidentally happens to be the same hashing algorithm that Bitcoin uses.
strictlycrypto : 485AE476D2EA0D8C72F0D6FA309E0F74DC200243E4A0DEDA9977707034F10F52
Strictlycrypto : E1648CC4433A55089D61C3EC78DE6C90725DA9C413FDF66411E1BFE1E1BABB87
You see how much the output hash changed just by changing the first letter of the alphabet? That is what we mean by the snowball effect. This property is how the blockchain gets its immutability. This is the reason why it is impossible to tamper data once it is inside the blockchain.
However, what if someone tampers the data BEFORE it enters blockchain? The thing is that even if people notice the tamper after it enters the blockchain, they can’t do anything about it. This is what transaction malleability means.
Now, the signature data/ witness data wasn’t only taking up a lot of space in the blocks, it turns out, that it is easily malleable as well, which in turn can change the transaction ID. In fact, it may make it seem like the transaction didn’t even happen in the first place.
It is not that confusing, let’s take an example and understand what we are talking about.
- Suppose Alice wants to send Bob 1 BTC
- She initiates a transaction to Bob’s public address and sends it to the miners for approval
- When the transaction is waiting in the queue, Bob can use transaction malleability to change Alice’s signature.
- Think of it like this, you are sending a cheque to somone, but before it can get to the bank, that person changes your signature and makes it look like it is coming from someone else.
- In these situations, Bobb will get his 1 BTC and then raise a complaint to Alice saying that he didn’t get any Bitcoins from her.
- Bob will eventually end up with 2 BTC instead of 1.
This exact hack was what was used to attack Mt Gox exchange. The attackers managed to siphon away $473 million worth of bitcoins, which was around 7% of the world’s supply of bitcoins, were stolen from the system.
So, the big question is, can malleability permanently destroy lightning protocols?
Wait…what? Then why did we spend so much time to go through all this content in the first place?
Well…malleability won’t destroy Bitcoins, however, it can make setting up these channels extremely annoying. There are only two ways that this can be solved:
- By either setting up multiple timeouts within the payment channels
- By introducing trust within the payment channels.
However, this is both extremely undesirable. Firstly, multiple timeouts are annoying and secondly, why should we introduce trust when cryptocurrency was supposed to be trustless in the first place.
This is why Segwit is so important for lightning network implementation. Segwit completely takes out signature data from the blocks so it takes away any chance of malleability.
Pros and Cons of Segwit
Alright, so let’s wrap things up here. What are the pros and cons of segwit?
- It increases the number of transactions that a block can take in
- (for users) it decreases the transaction fees
- It makes the transaction much less bulky by taking away the signature data
- Transactions now have much faster confirmation time because the waiting time decreases
- Helps in the overall scalability of the network
- It is a soft fork so the community didn’t need to go through hardfork
- Since the number of transactions in each block will increase, it may increase the total overall fees that a miner may collect.
- By putting away signature data, it helps in removing transaction malleability
- By removing transaction malleability it helps in the activation of lightning protocol
- Removes the quadratic hashing problem: Quadratic hashing is an issue that comes along with block size increase. The problem is that in certain transactions, signature hashing scales quadratically.
In simple terms, doubling the transaction amount in a block doubles the transactions and that in turn would have doubled the quantity of signature data. Can you imagine how much bulkier and time-consuming the transactions would have been? Spammers could have easily used this to slow down the network.
Alight, now let’s look at the dark side of the force.
- Miners will now make less from transaction fees for each individual
- Segwit demands a change in the overall blockchain architecture for Bitcoin, bringing in a lot of complexity. Simplicity is often the best way to go forward
- Because of the capacity, bandwidth, transaction increase, segwit will significantly increase the total amount o resources that are going to be consumed.
- As is evident by the creation of Bitcoin Cash, Segwit did manage to split the bitcoin community. Which was something they wanted to avoid in the first place
- Also, segwit, at the end of the day, is a sidechain. Sidechains need to be maintained by miners as well, however, there is no incentive for them to do so. Some reward mechanism must be put in place to incentivize the miners.
So, there you have it. The history of the block size debate, the eventual formation of multiple bitcoin forks. The creation of the most prominent fork aka Bitcoin Cash and Segwit. We have covered all that in detail in this guide. Now, this is a very touchy subject and we realize that some of our readers may have a very strong reaction to some of the things that we have written in the article. However, that is alright. The idea is to spark healthy debate and discussion. Sound off the in the comments below and let us know. Was SegWit te way to go forward, or has the community made a big mistake here. Let us know what you think and share this guide with your friends and communities!