Game Theory of Segwit2x and UASF
Amidst this crypto bloodbath, I have seen some strong sided opinions regarding Segwit2x, UASF, Bitcoin ABC, BIP141 and many others. I can tell there is a lot of confusion going on as well as misconceptions.
This article attempts to explain the key events that will be keeping the overall Bitcoin community abuzz over the next few months. I break this up to two parts; the first part describes What is happening and the second part aims to explain Why it is happening. If you already know that basics of the What, I suggest you to skip to second part, where I go into the game theory and incentives of the parties involved. The content does NOT take an investment stance as the article solely aims to provide clarity for you to make your own decisions.
Part 1: What?
Scalability
I first want to start by explaining why there is such a huge debate over the need for Segwit (Segregated Witness) or bigger block sizes. Currently, the Bitcoin network can handle about 2–3 transactions per second; compared to Visa’s 2000 transactions per second, we have a long ways to go.
We always knew that we needed to somehow scale in order for Bitcoin to become viable and replace modern payment systems. One of the first proposed solutions was either bigger blocks or faster block time.
It was quickly mathematically proven that scaling with bigger blocks or faster block time would surely decrease the security of the network due to longer propagation time and wasted work. I will not get into the technical details of this as it is very clearly explained in the GHOST Protocol paper which is what Ethereum uses a modified version of. In shorter, bigger blocks and/or faster block times causes miners to waste hash power on non-main chain. This makes it so a Sybil attack can happen at a hash rate less than 51% of the network hash rate, depending on how big or how fast the blocks are.
A bigger block hard fork also leads to miner centralization because the requirement to run a full node (includes mining) increases, certain nodes who can barely afford to run Bitcoin Nodes now will no longer be able to.
BIP141: Segregated Witness
Segregated Witness, first introduced by Eric Lombrozo, Johnson Lau and Pieter Wuille in BIP141, aims to increase the block size as well as fixing many other issues such as transaction malleability. Segwit is very attractive, the fact that the witness data is separated from the transaction Merkle Tree allows us to weight the witness data different from the transaction data (stripped of witness data). By using the Block Weight concept, we are able to fit more transactions into a block which is still compatible with what legacy nodes see. Legacy nodes will never see a block greater than 1 MB. On average, it is calculated that with Segwit, we can achieve the same amount of transactions as approximately a 2 MB block.
Some may argue that Segwit offering “2 MB” blocks is just a temporary fix because we are nowhere close to Visa’s speed of 2000 transactions per second (tps). However, removing transaction malleability allows us to build towards the lightning network which builds the foundation to off-chain transactions as well as atomic cross-chain transactions. Segwit will also allow for easier implementation of Schnorr Signatures (which, among several potential benefits, can be a way of aggregating multi-signature data together which increases the block capacity).
One other advantage Segwit offers is that it can be updated with just a soft fork because the block size recognized by legacy nodes is still less than or equal to 1 MB. This makes Segwit backwards compatible, which should create a much more secure transition. BIP141 activates Segwit if 95% of nodes signal “Bit 1” over one difficulty period (2016 blocks which is about two weeks).
There are some downsides to the current Segwit implementation. Peter Todd does mention in this paper that Segwit might create more incentives for validation-less mining, but this can easily be solved with a soft fork that requires for the previous block’s witness data as a precondition to creating a block.
The community has been very positive about Segwit in general and agree that it is the direction we should go to scale Bitcoin for the long term. It makes sense to be achieving efficiency before increasing capacity (optimizing transaction sizes before increasing block sizes). However, we were never close to reaching 95% signaling mainly due to lack of miner support. The expiration time of BIP141 is two years and the date will be November of this year, so there is now some urgency to activating Segwit. Enter BIP148, User Activated Soft Fork.
BIP148: User Activated Soft Fork (UASF)
Amidst the reluctance of miners to support Segwit, BIP148 was released in March of 2017 that deploys a time-based activation of Segwit. UASF states that starting August 1st, miners are required to signal version bit 1 or their blocks will be rejected. This could potentially create a chain split because if miners don’t signal bit 1, their blocks will not be accepted by UASF nodes.
If there is a chain split, even if the Non-Segwit chain is longer, a blockchain re-organization will NOT happen. A blockchain re-organization happens when a client discovers a different blockchain that is the actual longest-blockchain, which makes it exclude the previous shorter blockchain also known as orphaning. However, if the Segwit chain becomes longer than the Non-Segwit chain, there will be a re-org and all block rewards mined by the Non-Segwit chain during the chain split will not be valid.
If BIP141 or BIP91 has been locked-in, a chain split should not happen because Segwit should already be locked-in through either BIP91 or BIP141 and all other chains should re-org to the Segwit chain (unless an entity plans to hard fork/chain split, see Bitcoin ABC below).
I also want to note that if UASF does not gain any significant hash rate support, it could potentially be prone to replay attacks by high hash power mining pools. There is 15% minimum hash power support threshold UASF needs in order to even reach a difficulty change.
Segwit2x
In response to the UASF Proposal came the New York Agreement published by DCG at Consensus 2017 also known as Segwit2x. Segwit2x is a modification to the Segwit2mb proposal by Sergio Lerner; instead of a 95% signaling requirement, a reduced 80% signaling will activate Segwit Soft Fork in late July (BIP91) as well as a 2 MB Hard Fork in November. It is interesting to note here that the Segwit Soft Fork is “coincidentally” right before BIP148 UASF. This agreement was signed by many major Bitcoin Mining companies that adds up to about 83% of the network hash power. This was the miner’s retaliation to BIP148, UASF.
To elaborate on BIP91, Nodes will start signaling on July 21st and if 80% signaling is reached within any 336 block window (two days) before, Segwit will lock-in through BIP91.
Segwit2x should NOT create a chain split during Segwit activation but could potentially create a chain split in November’s 2 MB hard fork. The consensus code for the 2 MB hard fork is tested very limitedly and was NOT written by the Bitcoin Core Developers. On a positive note, the Segwit code in Segwit2x is basically a direct copy of BIP141, which was written by the has been tested extensively.
There is no binding code that states if Segwit is activated through Segwit2x, nodes will be forced to run the 2 MB hard fork in November. It is impossible to make a soft fork conditional based on a hard fork three months later, so it is possible that the hard fork will not even happen if Segwit is passed through Segwit2x.
Signaling, which was first introduced in BIP9, was never meant to be for voting or political use. The original idea was for coordination amongst miners and users for forks. Miners have now taken advantage of this to enforce their hash rate dominance as political power.
Bitcoin ABC (Bitmain)
Shortly after the release of BIP148 UASF, Bitmain responds with a UAHF announcement. In the case that the New York Agreement (Segwit2x) fails to activate, Bitmain will begin to privately mine their own blocks parallel to BIP148 UASF. If the hash rate support for BIP148 is strong, Bitmain will publicly release their mined blocks to the public for other miners to join.
This hard fork imposes a new consensus rule that states blocks that are less than 1 MB size will be rejected with an upper limit cap of 8 MB block size. Bitmain states that it is very dangerous for BIP148 to be chain splitting from the original BTC chain, giving miners and users no choice but to adopt Segwit without bigger blocks (against the Hong Kong Agreement).
This hard fork is probably the worst thing that can happen to Bitcoin right now and I am highly against it. I think this is what will essentially force Segwit2x agreement, no one wants a guaranteed chain split like this. I think that was the intention behind this proposal.
Part 2: Why?
Game Theory (Incentives and Mindsets)
In a decentralized protocol, game theory and incentives control the results as to what will happen. Now that we have briefly went through the different plans and proposals by all the parties in order to scale Bitcoin, let’s have a look at all the different incentives and motives involved.
UASF Standpoint
BIP148 UASF is basically an ultimatum from the users/devs to the miners. It is stopping miners from blocking Segwit with a timed activation. If miners don’t want a chain split, they will be forced to upgrade to Segwit. However, I don’t think the users/devs want a chain split; their action of UASF is basically pressuring miners to make a decision, they understand that a chain split would be very detrimental for Bitcoin.
I think the original intention of UASF was to get miners to signal for BIP141 before the UASF deadline to avoid a potential chain split. However, the miners were clever to react with a proposal to activate Segwit because they knew it was inevitable but with it came many other conditions.
As much as I am against potential chain split threats, the users were cornered into this decision. Without miner support, there was no way Segwit could be passed through 95% signaling because miners have so much veto power. The Bitcoin Core Developers really believe Segwit is necessary and that bigger blocks is not the solution for Bitcoin long term.
ASIC BOOSTS
One huge reason some major mining pools such as Bitmain does NOT want to support Segwit soft fork is due to ASIC BOOST incompatibility. Covert mining with ASIC BOOST basically allows for miners to gain an efficiency advantage over other miners, giving them a 30% savings on their costs.
Covert ASIC BOOST mining also causes empty block mining, a phenomenon where the protocol allows for miners to mine a block with only the coinbase transaction. Mining empty blocks is definitely detrimental to the Bitcoin network, especially when the mempool (a pool in which transactions are waiting to be picked up by miners) is always full.
There are indeed ways for Segwit to be compatible with ASIC BOOST covert mining. If we want Segwit to remain a soft fork, we would have to start over and rewrite Segwit. This is not ideal as the current Segwit has already been extensively tested and adopted by the industry (Litecoin). Another option would be with a Segwit Hard Fork; there are ways to change the Header format to achieve this compatibility.
Transaction Fees
Let’s step back and think about how we got here in the first place. Why is it that we are so rushed to activate Segwit all of a sudden? Transactions fees has gone through the roof this year and there are reasons as to why. As I mentioned earlier, ASIC BOOST promotes mining empty blocks while the mempool is full of transactions.
How do empty blocks affect the transaction fees? Imagine a room full of people and each one of them are waiting to buy a product. The longer you make them wait, the more they will be willing to pay due to urgency. Miners don’t care about not making the transaction fees from mining an empty block because they know this will naturally increase the fee of each transaction which is sitting there waiting for them to collect.
There are claims that miners are spamming the mempool with bogus transactions in order to drive up the transaction fees. This is similar to fake bidding at an auction house to get buyers to pay higher prices.
So why am I bringing this up? How does this relate to Segwit and scalability? Let’s ask ourselves why we are so rushed to get Segwit through. Due to the sudden increase in transaction fees, as many have mentioned recently, it currently costs a cup of coffee in transaction fees to buy a cup of coffee. This has changed the way businesses such as BitPay operates because users are less likely to use Bitcoin as a payment method due to it’s high transaction fees. Due to that, we need Segwit and Lightning Network to reduce the currently inflated transaction fees that are being paid to the miners.
Miner Power Play
Miners are a huge cause to the reason why the community/users want Segwit pushed through so desperately. They are now telling the community they can fix this by giving us Segwit, something the Bitcoin Core Developers worked very hard on the past few years. They are taking advantage of our desperation for Segwit, by forcing it with Segwit2x.
If we take a step back and look at the big picture here, all this is a political power play. This isn’t about Segwit at all. Segwit is just being used as a tool to increase their leverage. Miners want to use the desperation from the community/users due to a problem they caused to bring us Segwit as well as a hard fork through Segwit2x.
The ploy here is pretty simple, they basically want to change
https://github.com/bitcoin/bitcoin (Bitcoin’s original GitHub)
To
https://github.com/btc1/bitcoin (Segwit2x GitHub)
Why do they want to do this? In a decentralized protocol with no regulation, any party with power can leverage their position if they have the incentive to. Whether it is malicious or not (this is very subjective), you cannot blame anyone for their actions if it is to their own benefit.
If the miners successfully push Segwit through Segwit2x and through their GitHub, the Bitcoin Core Developers are basically being fired from Bitcoin’s management. It sets the precedent that from now on, the miners can do anything they want, change anything they want with the 80% signaling threshold. It will be easier politically to enforce rule changes that benefit them.
This isn’t the first time the miners have tried to pull a similar political power move. All the attempts listed below have failed in the past.
https://github.com/BitcoinUnlimited/BitcoinUnlimited (Bitcoin Unlimited)
https://github.com/bitcoinclassic/bitcoinclassic (Bitcoin Classic)
https://github.com/bitcoinxt/bitcoinxt (Bitcoin XT)
How likely is a Chain Split?
As the past hard fork attempts have failed, how likely will a fork be this time? This situation is sort of different. Segwit2x is essentially a hard fork masked by a soft fork we desperately need. If support for BIP91 or BIP141 is not strong and Segwit is not locked-in by August 1st, it is likely BIP148 will cause a chain split from either the original BTC chain or Bitmain’s hard fork.
If Segwit gets passed through Segwit2x, there will be a pending hard fork coming in November which is also a chain split threat. It is also very likely that Segwit is passed through Segwit2x with BIP91 and a hard fork is denied in November due to everyone’s realization of how unnecessary it is due to the optimism of the Lightning Network.
Is it all a bluff?
Could the threats of all these chain splits all be a bluff and were all attempts to shift power from one party to another? I don’t think any of the parties involved are willing to jeopardize a real chain split. People mention that miners don’t care about the long-term value of Bitcoin because they aren’t BTC hodlers, they can sell anytime. This is sort of true (although miners do indeed hold a lot of BTC) but what about the billions of dollars of ASIC machines that they are so heavily invested on? Those ASIC chips aren’t useful for anything but for Bitcoin mining.
The current miner’s mindset is to either push Segwit through in a way which it gives them more power (through btc1 GitHub) or delay Segwit as long as possible so they can keep benefiting from ASIC BOOST mining. No acting party here is willing to heavily devalue Bitcoin for the long term, which a chain split will definitely do.
One question we have to ask ourselves is if there really is a chain split, which chain will be valued more? Do miners really want to risk a chain split and hope that investors will value a chain with no management team (developers)? I don’t think they are willing to jeopardize tens of billions of dollars for a power move. There are definitely bluffs right now and it all depends on who will fold first.
Conclusion
In a decentralized protocol, no party can be blamed for leveraging their position for their own selfish motives. The current tug of war is a great representation of game theory in an unregulated space. In the end, I think everyone involved will eventually do what is best for Bitcoin long term. Miners understand the scarcity of Bitcoin, that the supply is ultimately fixed at 21 million. It makes sense they are doing everything in their power in the short term to accumulate as much as possible.
If miners get what they want and Segwit2x gets passed which includes the 2 MB hard fork, Bitcoin will lead to centralization. If Bitcoin was a company, the developers are the management team and the miners are currently the Board Members. It would not be a very smart move to fire the management team and jeopardize the future of the company the Board Members have so much stake in (ASIC Machines, BTC Shares).
It is to my opinion or my hopes that everyone with power involved wants to see Bitcoin succeed; they want to see Bitcoin go to the moon. There is a reason why Bitcoin has survived any attack in the past 8 years. This is just another internal obstacle Bitcoin should overcome and, compared to what we will have to battle in the future, this is just a small hurdle.
If this article was informative for you, please follow me on Twitter and my firm, CryptoParency, on Linkedin!
Disclaimer: The content published in no way constitutes an investment recommendation by CryptoParency.