Best practices in fork handling?

If you are looking for an article telling you how to write bulletproof blockchain state handling given fork edge conditions, I am not sure this article is it. I am not a Bitcoin expert. If you are looking to explore the possible edge conditions, then this article may help with that.

Block headers and forks

  • It links to the preceding block headers and naïvely represents represents the preferred fork for a given block height, if it has the most proof of work.
  • It has a merkle root which can be used in combination with a merkle proof to prove that any transaction that was mined in the block, was actually mined in the block.

The only fork that matters (until it doesn’t)

Forking incompatibilies

Services and forks

The proof against the other fork block cannot be used and it needs to obtain the proof for the block on it’s own fork. This is also not limited to merkle proofs, any other blockchain state that is related to a service processing a specific fork with the assumption it is the fork that will survive, will also produce results specific to that fork.

One source of blockchain state

How the Electrum wallet works for BTC and BCH is that it obtains the fork each server is using and picks one of the servers that is on the longest chain. This server is anointed the “main server”. Then it queries the full state of the wallet against the “main server”, and updates the wallet to reconcile with the fork the new server is on. All state updates now come from the “main server”. If it turns out the wallet is following the wrong fork, the user can go to the network dialog and force the wallet to connect to a specific server that is on the right fork.

This has long been a thorn in the side of ElectrumSV in that it is entirely possible to not correctly process reorgs and have a wallet with transactions in the wrong state — however, this does not matter so much for BCH or BTC where the proofs are discarded after transactions have been verified as having been mined in a block.

Multiple sources of blockchain state

Let’s say you are receiving notifications of blockchain state from a server for new blocks, but have no way to specify that you want it for a given fork. If the server provides you with the changes relative to another viable fork, then you can store it for processing in case you need it. If the server reorgs, it is responsible for sending you the changes above the reorg height to ensure it delivers you the state you asked for. In this case you did not miss any changes, even if the fork was different.

Let’s say you are receiving notifications of blockchain state from a server for new blocks, and can notify the server you are following a fixed fork that turns out to be the wrong one. The server will have processed the other fork in parallel, and will never reorg, so you will have missed out on the changes for the fork that lives. You may have to pay it additionally to reprocess those blocks to look for the things you are interested in. Alternatively, the server might follow all forks and notify of all changes, which might be a better model — but I do not believe any current services do this.

My suspicion is that the best way to do an application is to use some heuristic to choose the fork to follow. To take the state from services and reconcile it, storing it in case it is needed, and to be aware of inconsistencies. In case there it is not obvious which fork is the viable longest honest fork yet, notify the user that there are some constraints imposed.

Summing up

There are no answers in this article, just some consideration of the possible problems.

The “early days” disclaimer

It is interesting to consider that these things do not exist in BTC and BCH for us to wholesale adopt and build on. That for all the years BTC has been around, now ten or more, there has never been any serious usage to require these the time and money invested to build this out.

But here we are and this is happening now on Bitcoin SV. It will take us time and some iteration, to reach the solutions and best practices to be used in the longer term.

Make it someone else’s problem

Some possible examples of different ways to do wallet as a service are Handcash Connect and Relysia.

Best practices

That’s it. This article isn’t intended to provide any answers, just scratch an itch.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store