UASF BIP148 Scenarios and Game Theory

I’ve written a good deal about BIP148 already, and recently, there’s been a lot of speculation about what will happen once the UASF starts on August 1. In this article, I’m going to lay out some potential scenarios of BIP148. Some caveats before we get started:

1. All possibilities, up to and including the destruction of Bitcoin as we know it are on the table. One side may not be willing to do X, Y or Z for the sake of Bitcoin and be a gracious loser, but that’s not a safe assumption. We consider all possible moves, no matter how “reprehensible” they seem in terms of collateral damage.
2. I’m not going to be able to cover all possible scenarios. In fact, I’m not even going to be able to think up, let alone address, even 10% of possible scenarios. Moves can get as creative as the people involved and that should never be underestimated.
3. You should definitely not count on things happening the way I’m outlining. Knowing about a scenario generally will make the losing side take action to avoid it.
4. I’ll examine scenarios from the simple to complex. Generally, the more complex the scenario, the more damaging it will be to Bitcoin.

I’ll have some thoughts on what will ultimately matter in the conclusion, but the purpose of this article isn’t to predict the future, but to show how complicated and damaging everything can be.

For the sake of clarity, I’ll call the two sides “Users” and “Miners” with the UASF BIP148 fork being initiated by the “Users”. The names aren’t strictly indicative, of course (there may be users on the Miner’s side and miners on the User’s side), and are adopted for convenience. With that in mind, let’s take a look at some scenarios that UASF BIP148 can produce.

Miners Capitulate

This is perhaps the easiest scenario to understand. The Miners, not wanting to risk a soft fork, decide to signal for Segwit (through Segwit2x, Extension Blocks or straight BIP141) and manage to lock in Segwit before August 1. A straight BIP141 capitulation is the ideal scenario for BIP148 advocates as that would mean they’d get Segwit and they wouldn’t have to go through with a soft fork.

Segwit lock-in via Segwit2x or Extension Blocks will also create a situation where BIP148 won’t do anything. This won’t necessarily be ideal for BIP148 advocates, but will nevertheless avoid the soft fork altogether. Segwit will be in Bitcoin, so this scenario can be considered at least a partial win for the Users, even if some larger block size comes along with it.

Users have Minimal Hash Rate

In this scenario, the Users have something like 0–13% of the July 31 network hash rate on August 1. The obvious consequence of having such a low hash rate is that blocks will come very slowly (one per 80 minutes+). This leads to two big problems.

The first problem is that there will be a tremendous backlog of transactions on the Users’ fork. Transactions will take a very long time to confirm, and since block space is scarce, fees will be very high. The cost and time of transacting Users’ fork coins may put downward pressure on price. That, in turn, may cause hashing power to move to the Miner’s fork and make the problem worse.

The second problem is that there will be doubt whether Segwit will activate on the Users’ fork! This is due to the fact that Segwit activation requires 95% of the blocks to signal in a 2 week network difficulty adjustment period before November 15. However, since the Users have <13% of the hash rate, a single network difficulty adjustment period will take >15 weeks. August 1 to November 15 is about 15 weeks, putting activation of Segwit (BIP141) on the Users’ fork in doubt.

This brings up the obvious question. Why fork at all if Segwit won’t activate on the fork? After all, wouldn’t it be easier to try a flag day UASF after November 15? The more obvious it is that Segwit won’t activate, the less reason there is for hash power to stay on the Users’ fork.

Miners Do Nothing

In this scenario, the Users have something like 25–75% of the network hash power. Like a deer frozen by headlights, the Miners in this scenario don’t react in any way.

If the Users’ fork has 51% or more, there will be only one branch and that branch will only accept blocks signaling Segwit. There may be a lot of orphaned blocks and perhaps reorgs that go 3–4 blocks at times. This will make it much easier to double-spend, so exchanges and merchants will likely not take transactions with less than 6–8 confirmations, but otherwise, things will go on mostly as normal. I will note here that the 51% to 65% scenario is actually more complicated, but will, for the sake of convenience, refer the reader to the article I wrote.

If the Users’ fork has somewhere below 50%, then there will be two branches, a User’s fork and a Miners’ fork. If at some point, the Users’ fork gains more hashing power and has a longer chain than the Miners’ fork, this is where the fact that UASF is a soft fork comes into play. The Miners’ fork is then wiped out. That is, all the blocks on the Miners’ fork are replaced with the Users’ fork.

No amount of confirmations, then, on the Miners’ fork can really be trusted and this will cause a good deal of disruption. Of course, exchanges and merchants can still accept coins from the Miners’ fork, but any coins accepted or distributed on the Miners’ fork in this scenario are subject to simply disappearing and constitutes a large risk.

This wipeout risk will add tremendous incentive for the Miners’ fork to eliminate this risk, especially as the Users’ fork catches up to the Miners’ fork. But in this scenario, we assume the Miners do nothing, and the risk never goes away, perhaps due to infighting or slow development of a solution.

Note from the Miners’ perspective, UASF looks very much like an attack. This is because UASF looks to them like coercion (specifically to signal for Segwit, and nobody likes being told what to do, even if they agree). Thus, even if this scenario occurs where the Miners don’t respond as a collective, there very well might be individual responses that may try to hinder the growth of the User fork. Note that in a scenario like this, it’s very dangerous to transact on the Miners’ fork.

Miners Permanently Fork

As mentioned in the last scenario, there is already incentive for the Miners to eliminate wipeout risk. There is another risk for both chains and that’s replay risk. To explain both risks, let’s look from the perspective of an exchange.

During this time, there will be tremendous demand for an exchange to list coins from both the Users’ fork coin and Miners’ fork coin. After all, UASF advocates will want to sell their Miners’ fork coin and buy the Users’ fork coin. For an exchange to be able to offer this, there are two primary transactions on the blockchain that they have to be able to do on both chains in order to service customers: Deposits and Withdrawals.

Normally, exchanges credit deposits after 3 or so confirmations. When there’s wipeout risk, however, no number of confirmations will suffice. If the Users’ fork can overtake the Miners’ fork after 100 blocks, some deposits with 100 confirmations would be invalidated! An exchange would be taking on risk to accept deposits on the Miners’ fork. This risk gets greater as the Users’ fork catches up to the Miners’ fork.

In addition, exchanges normally pay out withdrawals without much thought to replay attacks. Without replay protection, when an exchange pays out 5 BTC to the Users’ fork, they may unknowingly also pay out 5 BTC to the same address on the Miners’ fork. The same thing can occur the other way, where 5 BTC paid out on the Miners’ fork may unknowingly also pay out 5 BTC on the Users’ fork. This can be overcome with software that makes sure a transaction isn’t also valid on the other fork, but this can be tricky to implement and may have bugs. Coinbase, for example lost a lot of money on replay attacks when Ethereum split.

Thus, to list both Users’ fork coins and Miners’ fork coins, exchanges will demand both wipeout protection and replay protection.

Here’s the problem. In order to offer such protection, the fork between the coins has to become permanent. At least as Bitcoin is currently constituted, there is no way to offer wipeout or replay protection without also eliminating the possibility of emerging with a single chain. Yet, as we’ve seen, people will demand the listing of coins from both forks. Thus, it’s likely that the Miners will hard fork.

This can be achieved several ways, but something like changing the transaction version (currently 1, but this can be hard forked to be 2 on the Miners’ fork) will work fine. In addition, since the Miners will be hard forking anyway, they may also want to add 2MB blocks as well. Heck, they may even hard-fork to Segwit (immediately, as opposed to waiting for lock-in + activation) as to remove an argument in favor of the Users’ fork.

Thus, you may see a very strange situation where the Miners’ fork will have Segwit and the Users’ fork not have Segwit (due to having less than 13% hash power and not activating in time). Talk about weird scenarios!

Miners attack the Users’ Fork

In this scenario, we assume the Users’ Fork has <33% of the hash rate and the Miners’ Fork decides to attack the Users’ Fork. The purpose of this attack is to make it unsafe to transact on the Users’ Fork.

The simplest attack would be a block reorganization attack and it works like this: Say the Users’ Fork mines 10 blocks in the 10 hours after midnight, August 1. The Miners dedicate slightly more hash power than the entire Users’ Fork to secretly to mine 11 empty blocks signaling Segwit starting at midnight. These blocks are not released to the network and take less time due to the higher hash rate. As soon as that 10th block is mined on the Users’ Fork, the Miners release the 11 empty blocks. The Users’ Fork immediately reorgs and 10 blocks worth of transactions are now suddenly thrust back into the mempool.

This is very similar to a wipeout, except it’s done by explicit attack. Exchanges and Merchants that received coins on the Users’ Fork may now find that the deposits/withdrawals are no longer are valid. Knowing an attack is in progress, they may halt any deposits, withdrawals and payments on the Users’ Fork.

The Users’ Fork at this point has two options. They can either keep the current proof-of-work and defend against attacks, or change the proof-of-work algorithm. They’re separate scenarios, so let’s examine each separately.

Users attempt to defend against Miner Attacks

In the previous scenario, the Miners attacked by using empty blocks. So, to defend against that attack, the Users’ Fork decides to change the rules so that empty blocks are now no longer allowed. This can be implemented as a soft fork and can eliminate the previous attack.

The new software has to be distributed to everyone using the Users’ fork and has to be deployed at the same time to prevent even more branches than the 2 that already exist. The Users code, test, package and distribute the software in a Herculean effort that takes 8 hours and the Users’ Fork manages to add this rule on midnight, August 2. All economic nodes manage to upgrade the software in the small time window.

The Miners see this software update (it’s open source) and decide to attack again. The attack is exactly the same (11 blocks secretly mined in the time it takes Users’ fork to find 10), except with an extra transaction in each block as to avoid the new soft fork rule. The Miners manage to wipe out 10 blocks worth of transactions on the Users’ fork.

The Users can do another soft fork to prevent this attack, this time not allowing any blocks with less than 20 transactions. The Miners again see the software update and can do another block reorg attack with 21 transactions per block. This can repeat over and over and becomes something like a game of whack-a-mole.

As long as the software is open source, based on proof-of-work and Miners control more hash power, the Miners, with superior hashing power, can always find some avenue of attack. During such attacks, transacting on the Users’ Fork is very difficult since transactions can get wiped out at any time, rendering the Users’ Fork difficult to use. Note that in a scenario like this, transacting on the Users’ Fork is very dangerous.

Users change Proof-of-Work

In this scenario, Users change the proof-of-work algorithm as to defend against the hash-power-based attacks.

This is a much bigger change, obviously, and a hard-fork. Hard forks are very difficult to roll out smoothly, which is why the Core developers have normally asked for 6 month to 18 month time frames for rolling them out. By contrast, this change would have to be rolled out in a few days, perhaps even a few hours. Further, hashing power in the new proof-of-work would have to be secured in a way as to have a much smaller chance of getting attacked. For example, if the new PoW algorithm was only mine-able on CPU’s the Users would have to secure large farms of CPUs to defend themselves.

Note this doesn’t guarantee that the Users can defend against the attackers. They may very well still be vulnerable to attack (in the CPU scenario, the Miners could prepare by buying botnets in anticipation of just such a PoW change).

In this scenario, Users are attacked by Miners, but it’s entirely possible that Users can attack the Miners if the Miners have the minority hashing power. Whoever has the minority hashing power chain may get attacked and their fork will be less stable, less usable and risk having an embarrassing or harmful deployment error.

What this means for you

So what does this mean?

You should be very careful about transacting after August 1. There are scenarios where your transaction will get wiped out no matter which fork you choose. Both chains have some wipeout risk and I imagine most people will be hesitant to do anything until there’s some resolution.

Conclusion

Believe it or not, I believe the fight will be even nastier than I’ve laid out. These are only rough first-order calculations of the game theory implications. There are likely to be many more moves, each with their own scenarios just as long as this article.

It’s impossible to analyze every scenario, but it’s possible to get an idea of the strength of each side. Here’s what will matter in this upcoming conflict:

1. Mining Hash Power — This one is one of the most important as hash power determines which side can be the aggressor if they so choose. Defending against all possible attacks is much harder than preparing a single attack.
2. Coordination — The side that agrees on what to do instead of infighting will obviously do better.
3. Development/Deployment Quality and Speed — As the situation changes, the side that can more quickly develop and deploy usable attacks and defenses will have an advantage. A slow moving side is obviously more vulnerable than a fast moving side. Oddly enough, the more centralized one side is, the faster they can move, which is a bit against the ethos of Bitcoin and naturally lead to authoritarian structures.
4. User Sentiment — I put this one last because the others will influence this one more than the other way around. Still, having users that are willing to stick with your side will matter as they will provide the liquidity for your side’s coin.

Do you have any questions about different scenarios, possible attacks, etc? Please add to the comments as I’ll add another post later this week answering your questions.

Want to get curated Technical Bitcoin News? Sign up for the Bitcoin Tech Talk newsletter!