What if…

Today, Charlie Lee posted a series of tweets detailing some concerns he has with Bitcoin Unlimited being adopted in exchanges: https://twitter.com/SatoshiLite/status/839673905627353088

The crux of the argument is what if post-fork the 1MB minority chain were to regain hash power and eventually overtake the large block chain?

I was in the middle of a response when Gavin Andresen posted an excellent rebuttal so I’ll just include that here (link):

Yes, IF the old 1mb chain survived without a difficulty reset hard fork…

… and IF speculators managed to pump up the price of that less-functional, less-secure chain so it was more financially attractive to mine…

… and IF the financial reward to mine on that chain was high enough for long enough to overcome cost of coinbase transactions on the big chain that they would never get to spend (because the 1mb chain difficulty catches up and passes the >1mb chain)…

… THEN there is an easy, already-in-the-code way to stay on the >1mb chain: just call invalidateblock with the hash of one of the 1mb chain blocks.

All of that said: there has always been worries about ‘what if somebody causes a really huge chain re-org’ — e.g. they spend five or ten million dollars to produce 144 empty blocks faster than the network and then cause chaos by unconfirming a day’s worth of transactions.

I think if that happened (extremely unlikely, in my opinion) everybody would just invalidateblock the big re-org and go about their business, and then agree that big re-orgs due to ‘surprise’ chains are simply unacceptable.

And yes, that does contradict the technical definition of ‘bitcoin’ I proposed a little while ago. Modifying that definition to have a notion of ‘…. and doesn’t invalidate settled transaction history’ is probably the right approach, but ‘settled transaction history’ is a pretty fuzzy concept.

So in summary, each individual could choose whether they wanted their node to follow the most-work chain (the default), or a particular minority chain. An exchange may want to run 1MB and large block clients simultaneously. In this case it would want the large block client to stick with the large block chain “no matter what”. This can be easily be done by calling “invalidateblock” for a block on the 1MB chain as soon as the fork occurs.

You now might protest “what about following the most difficulty chain and Emergent Consensus?” First of all, exchanges represent many users so an exchange would want to remain on a minority fork to pay out those users who cling to it. Second, by using “invalidateblock” Bitcoin Unlimited allows every user to individually choose what he/she wants to do. BU is about giving users the power to make choices rather than making it for them. And finally, this strategy allows users to make this decision in the future. This is important because while I would tend to choose to follow the hash majority fork, there may be compelling reasons why a person would follow both. The most compelling reason is if the 2 forks have each inhabited separate economic niches — for example, if the 1MB chain became a settlement layer and the >1MB chain becomes peer-2-peer digital money. I personally think that the >1MB chain can outcompete the 1MB chain in all ways, but if this possibility occurs we should not ignore it. It is better for today’s Bitcoin users if Bitcoin expands into 2 incompatible economic niches than if an altcoin does because in the former case Bitcoin users will have value on both chains.

Also, I’d like to add one more “IF” to the list:

… IF you choose to post in a highly public forum like twitter, you will receive a highly public answer. BUT you could instead choose to explore these important engineering questions privately or semi-privately with the BU team so we can actually help Coinbase come up with a strategy in a “safe space”.

As for what Coinbase should call each fork, I think that any attempt to cozen some technical “story” into determining this social/political decision is ignoring the fact that the process of Nakamoto Consensus (i.e. Bitcoin) both allows and expects forks. So both sides will call themselves “Bitcoin” and will have reasons to do so that their side sees as valid.

I think that what is most important is what will be most advantageous to Bitcoin? And I think that the answer to that question is that the fork that is the economic and hash power winner should ultimately be called “Bitcoin” and “BTC”. This will provide continuity for the majority of people in the world who do not care about these details and/or show up long after the issue is settled.

But if your exchange plans to allow cross-fork coin trading, you have to distinguish the forks while the feature is provided. Since we do not know what fork will be the winner, I would explore calling both coins something descriptive and a bit awkward, for example “Bitcoin (1MB)” and “Bitcoin (Large blocks)”. I would not attempt to create industry-wide consensus on this name because you do not want it to become a standard. Next, pick a relative price and hash power ratio and if one fork exceeds the other in both of those levels, revert to calling that one Bitcoin and leave the other as is.

Things are easier if an exchange chooses a fork (i.e. does not allow trading between forks). It can avoid updating most of the UI by calling its choice “Bitcoin” / “BTC”, announcing its choice somewhere prominent, and holding any other fork coins it receives for a periodic disbursement to anyone who wants them. Let’s call these the “active” and “holding” forks. Now, if the exchange chooses incorrectly (if enough economic activity leaves its fork), it can then announce a “cut-over” date where the roles of “active” fork and “holding” fork are swapped.