Hard Fork Risk Analysis: If the worse happens, how bad can it be?

This post is a culmination of about a year’s worth of thoughts and research that I have been informally gathering, which started with a simple question that started last year when I first read a piece which was written in the middle of the Bitcoin XT heyday describing what would be so bad about having 2 persistent forks by core developer, Meni Rosenfeld.

Forks are not scary, they are upgrades!

Forks are not scary, they are upgrades!

The post described the general understanding of forks at the time, and it was in this context that I wrote my original piece which was very much a pro-Core stance on the dangers of hard forks.  I was wrong on some of my assumptions when I wrote that, which I have over the course of the year corrected, but nevertheless that original piece earned me many twitter RTs and ‘follows’ by core devs and supporters at the time (who have mostly now, funny enough, all banned me).

Since a year has passed, and we had a hard fork situation happening in the wild (with Ethereum) I think it’s worth cementing all the collective knowledge I have accumulated on this issue to help educate and dissuade further FUD spreading by media handlers with ulterior agendas.  I’m going to ask (and hopefully answer) all the taboo questions that every person in Bitcoin has wanted to ask but was afraid to and grapple with the worst case scenarios resulting in a Hard Fork. I will hopefully show that even in the worst possible outcomes, the situation isn’t as bad as some would make it out to be (and that includes the me from one year ago).

To be clear, I’m writing this analysis assuming the worse case scenario happens, which is that a minority fork persists regardless of the overwhelming economic arguments that it cannot realistically happen in Bitcoin (due to miners not wanting to lose money).  This will assume that some of the economic minority and a few miners will continue to run the minority chain despite extremely long confirm times and drastically reduced security due to centralization post hard fork.  I will use the analysis of this worst case situation to prove by induction that the persistent fork scenario cannot persist in the long run.

Let’s start with the incorrect assumption that I myself was guilty of making a year ago, in which I stated it would be a problem if the 2 forks did not converge as it would threaten the fungibility of coins:

Consider Alice, who uses wallet A, and Bob, who uses wallet software B.  Wallets need to communicate with nodes to get their block confirmations. If wallet A is connected to a Bitcoin (John) chain node, and Bob’s wallet B is connected to a node running the XT (Judas) chain then they are no longer going to see the same block confirmations, and they won’t know about it!  Alice will send bitcoins to Bob, she sees a confirm, but Bob will never see a confirm, if the coins are originally minted from a post-Judas block.  If it is from Jesus block or less, then her transaction with Bob will work and be seen by both of them, BUT then Alice can re-spend those same coins with a counterparty on the John chain!

Blocksize Limit the Schism that divides us all, JerryC

This actually isn’t that bad of a situation, but you have to think hard to realize why.  The first assumption that I made was that Alice would be able to easily double spend her pre-fork coins.  This is far from the case as it would require some specialized wallet and collusion with a mining pool in order to do so. Additionally there are other difficulties as you will see below. The other incorrect assumption that I made was that Alice would be oblivious to the fact that she was spending A coins when Bob was expecting B coins, and thus manage to lose her coins as Bob never sees the txn because it contained UXTOs that B fork does not recognize (Alice is using post fork minted A coins, which is to say, coins that were created from a coinbase txn in a block only valid on A fork). Why was this assumption incorrect?  In short because I failed to consider the UX considerations of normal bitcoin transactions.

The missing fact… UX and humans, not robots

Most of the time when one is shown a QR code to pay, one generally has a pretty good idea of what the amount is equivalent to, in real-world terms.  A coffee is about $3.50, a pizza $15 etc.  The fact of the matter is that unless the 2 persistent forks are about equal in market value (highly unlikely given the fact that a fork wouldn’t be attempted unless it had the majority hashpower) then the amount of the purchase in fiat terms displayed in the wallet software would be sufficient to warn Alice that she may be paying with the wrong coin!

For example, if Alice were paying for a pizza, which was $15, and she was on the majority fork ‘A’, which was currently trading at $700 per coin, and the pizza man, who is using the minority fork bitcoin ‘B’ which was trading at $100 per coin, and they both were oblivious that a fork had happened, then when the pizza man creates the QR code to receive $15 from Alice, the equivalent B bitcoins he would be requesting would be 0.15 BTC (B fork). Now, when Alice scans this payment request, she will see the request for 0.15 BTC, but her wallet is on A fork, where the value of the coin is different.  She will see this pizza costing her the equivalent of 0.15 x 700 = $105!! Surely, at this point, she will know something is amiss, and inquire why this pizza was so expensive.  And even if Alice were to go through with this transaction, and sent them to an address that Bob was not monitoring, Bob would likely be able to refund Alice the coins if she requested as he possesses the private key for them.

So you see, in the worst case scenario, where 2 users on 2 different chains try to transact with each other, they will always be able to do a sanity check to see if what they are paying with is reasonable, and thus can reasonably be assured that fat-finger mistakes can be avoided.  This applies even more so to transactions of larger amounts.

Before proceeding I feel I must clarify some terminology:

Undetermined coins: Pre-fork UXTOs or coins that existed before the fork, can be used on both forks after a split, and we will call these undetermined coins. If a coin is not undetermined, it will exist and be valid only on A fork or B fork, but not both.

So how about the case where users are spending coins from pre-fork coinbase txns, which are valid on both chains, or undetermined coins? Well there is certainly no chance of coins being sent to an address which Alice has no control over with Bob not knowing of it in this case, as pre-fork UTXOs are valid on both chains.  Alice would still have the visual sanity check of the wallet software showing the fiat value of the transactions being what Alice expects, but if she still wishes to go through with the transaction, then Alice either overpaid for her pizza or underpaid.  Let’s look at these 2 cases individually:

  1. Alice overpays for her pizza.  If A coin is worth more than B coins as in the previous example, Alice just paid $105 for a $15 dollar pizza.  This kind of sucks for her in that she lost $90 of value, but it is important to note that Bob did not really gain it in this exchange.  He received exactly the number of B coins that he demanded, 0.15, and got paid an equivalent of $15 in value.  So where did the $90 go?  Well that value was given up by Alice by effectively converting her pre-fork or undetermined UTXOs to B coin.  It is now sitting at an address owned by Bob on a chain that he isn’t monitoring.  He could be incentivized to setup a wallet on A fork just to extract this value via an exchange, though by doing so he would probably realize that keeping A coin is a better store of value than the coin he is currently using.  If most if his business was conducted with undetermined coins, he may find out that his total balance of his business wallet is significantly more (7x more in this example) using the A fork wallet instead!  He would then stop using B coin, and just switch to A coin wallet. You may also wonder why Alice would want to do this losing trade in the first place.  Well that is a very good question, she wouldn’t.
  2. Alice underpays for her pizza.  If A coin is worth less than B coin (let’s assume the fair market values of the coins are reversed, A coin @100, B coin @700) then Alice is more than happy to try to buy her pizza with 0.021 BTC ($15/700) as that means her pizza looks to cost only $2.14 from her point of view.  This seems to be a great deal for her, so she will attempt to do this every time.  Once again, Bob gets the exact number of BTC that he requested and he delivers the pizza, so he doesn’t care.

In both these situations, it is important to note that Alice always sends the same txn to both forks and it ends up being mined on both forks.  In both cases Bob gets the coins he demanded, and the fact that he also received A coins in the other fork is not important to him.  Indeed Alice sent Bob both B and A coins, and actually you cannot double spend the same UXTOs on both chains because the txn that Alice sent is independently mined on both chains.  So there is no double spend risk. (Alice lost control of the undetermined coins on both A fork and B fork when she pays Bob on B fork)

What’s more, the only thing that Bob could likely do is to keep 2 wallets, and whenever somebody paid him with undetermined coins, he would sweep up the coins he doesn’t support and sell them on an exchange to extract the excess value that he got from Alice. (in this case, Alice gave Bob an extra $2.14) This would mean the minority fork coins would be net sold on every exchange.

If you take a step back and think about this from the perspective of a rational economic actor, you will see that Alice will be always be incentivized to follow strategy #2, and effectively convert her A coins to B coins.  And Bob’s will always be incentivized to sell any extra A coins that he received (if he cares at all) at an exchange and once again depress the fair market value of A coin.  What results in the end is that the fair market value of A coin will go to zero, and thus its fork will be worthless.  We have also shown that strategy #1 is not logical for the payer as Alice has no incentive to do the transaction at a loss, and even if she does, then Bob is incentivized to switch his whole business to the majority coin if he gets a lot of irrational Alice’s who are willing to give up value in order to support her preferred fork.

But what about the new coins minted on each respective fork? The determined coins. What if enough natural commerce is done purely in one chain or the other, and they do not cross?  In this case, two forks can coexist the longest as their coins don’t get inadvertently converted by the worst case scenarios I explained above.  But I would argue that in this case, we actually have no problem, as each fork essentially is acting as its own separate coin, so we have no reason to worry.

Thus, it seems reasonable to assume that most normal economic actors like Alice are not zealots and will happily follow the economic efficient strategy and the value of a minority fork coin will never be able to surpass the majority fork coin after any permanent fork.  And any inadvertent mispayment which crosses coins only serves to depress the value of the minority fork coin even more.  Thus by induction, we can see that in the long run, the minority chain will have no value, and thus most rational actors will choose not to transact on it.  So let’s get on with forking already.  There is nothing really to fear but fear itself.

/EOL

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *