Chainmerger — unifying blockchains after a fork

Eric Wall
5 min readSep 24, 2017

--

“We don’t have a merge process in Bitcoin. There might be some future ideas eventually in other cryptocurrencies that might allow for merges but as Bitcoin stands right now, there really is no way to merge two chains that are incompatible.”

- Eric Lombrozo (source).

When the participants in a cryptocurrency community cannot come to consensus on a mutual path forward, their users may agree to disagree and choose to proceed with consensus rules incompatible with each other, forking the blockchain & splitting the coin into two. After such an event, there are currently no good ways of merging back into one again, even if the users want to.

In this article, I propose one way of approaching this problem.

I will use Bitcoin (BTC) and Bitcoin Cash (BCH) in my example, but it also applies to other cryptocurrencies and future forks such as SegWit2x. The resulting technical monstrosity on display here is purely a theoretical discussion piece and should not be viewed as a suggestion for any real-world application, but may give food for thought for how future chainmergers could be designed. I know everyone has a lot to read these days, so I’ll try to make my point as quick as possible.

Chainmerger

This chainmerger proposal requires a hardfork from the perspective of both the Bitcoin Core and Bitcoin Cash protocol. The new Bitcoin node would need to bundle the legacy consensus code of both protocols and validate different block height intervals differently. This in itself is not unusual, as Bitcoin ABC nodes already perform this type of block height sensitive validation today (they validate blocks #1–478558 according to Bitcoin Core consensus rules and blocks >#478558 according to Bitcoin Cash consensus rules). The difference in this example being that the chainmerger node syncs both blockchain histories post-#478558 in parallel and validates both chains.

A chainmerger between Bitcoin and Bitcoin Cash, forking at block height 478558 and merging back together at some future block height X+1.

The chainmerger hardfork event starts when some predetermined block height X is reached on both chains, after which they will reject any blocks extending the respective chains under their existing consensus rules. Instead, the chainmerger node will demand a special merger block at height X+1 that implements hashPrevBlock differently —it will hash the concatenation of the blockheaders of both chains rather than just the blockheader of one chain. Moreover, block #X+1 must of course also abide by the new, mutual rules that lay the foundation of the newfound consensus that led to the merger.

Undoubtedly, attempting this type of merger would cause a myriad of technical issues, most of which I won’t even attempt to address here. Rather, I will focus on two simple but seemingly conflicting requirements that are both on their own fundamental to Bitcoin.

  • Each UTXO on Bitcoin or Bitcoin Cash must each also be spendable on the merged chain using the same private keys as before the merge
  • The 21M total cap must remain untouched

At the time of writing, 126,700 additional BCH has been mined alongside BTC. More crucial is the fact that many BTC holders have moved their BCH (essentially double-spending certain UTXOs). Attempting to merge both conflicting UTXO sets would dilute the circulating BTC supply in an unsatisfactory way, so we know we cannot simply merge the two chains this way. Instead, I propose that each of the double-spent UTXO coins that has been created as a result of users moving BCH are weighted according to some coefficient such that the total of both conflicting UTXO coins amount just one coin, i.e. 1 BTC + 1 BCH = 1 BTC (merged).

Ideally, this coefficient should correlate with the market value disparity between the two coins, which at the time of writing is BCH/BTC 0.1138:

0.8862 * BTC + 0.1138 * BCH = 1 BTC (merged).

However, consensus discussions of this sort can be expected to drag out over time, and as the BCH/BTC price will likely fluctuate in the meantime, participants may drop in and out of consensus making consensus on the coefficient a moving target, and the price on exchanges subject to manipulation. Luckily, there is a better, deterministic metric we can use which is the Proof-of-Work disparity itself.

Chart from fork.lol.

From these numbers, we can estimate how much miners have been mining on each chain since the split (in trillions of hashes):

40239.55 - 32754.53 = 7485.02 on BTC
33787.07 - 32754.53 = 1032.54 on BCH

We can use these metrics to define algorithmically to which extent split UTXOs should be honored at the point of the merge. Using the current PoW values, we would get the coefficients 1032.54 / 7485.02 = 0.1379 and 1 - 0.1379 = 0.8611, thus:

0.8611 * BTC + 0.1379 * BCH = 1 BTC (merged).

Note that BTC UTXOs to which there are no conflicting BCH UTXO counterparts would still be honored 1:1. This means that holders who did not move their BCH would still have the same BTC balance before and after the split/merger as if nothing happened, while holders who sold their BCH would take a -13.79% haircut on their BTC balance, which may be atleast somewhat compensated by the profit they made when selling those coins for BTC (or fiat). Holders that kept equal amounts of both coins would have the same BTC amount as before the merger. Users that decided to invest in BCH instead of BTC will get 0.1379 BTC for every BCH they bought.

Discussion

The long-strawers of the bunch in this chainmerger are the users who bought BCH at lower prices than 0.1379 and the users who sold their BCH over that same price. The users of the opposite category, meaning the users who bought BCH at higher prices than 0.1379 and users who sold their BCH at lower prices 0.1379 makes up the short-strawers of the bunch. Arguably the biggest losers of this deal are the users who bought BTC after August 1st, who would have their BTC balance deducted by -13.79% with no other compensation. This would probably be unacceptable to most BTC holders, although one could argue that the users who bought only BTC and not BCH got their coins at a discounted price at the time, since a part of the community and hashpower was allocated to a different chain at the time of their purchase. There are also many other issues with this approach that one can think of, one instance being he game theoretical incentives it creates for miners to buy BCH and switch to mine BCH to increase the BCH merger coefficient that would need to be addressed.

In closing, Bitcoin and Bitcoin Cash are probably not good candidates for merging and this post does not aim to champion such an idea. The idea being discussed here is only meant as thought play for how chainmergers may be designed in last-resort type of instances where both groups deeply regret splitting.

Thanks for reading!

>> Link to my Twitter.

--

--