Best practices in fork handling?

Block headers and forks

Any block header has some well known properties of interest to a wallet:

  • 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)

There is no observably correct official Bitcoin SV blockchain. For most mined blocks, this is not a problem as there is only one block mined at a given height. But occasionally there will be competing blocks mined or even a dishonest attack on the blockchain. There will be times when the observer will not know which of the new blocks mined at the same height are the ones that will be further built on.

Forking incompatibilies

It is very possible for a wallet to follow the wrong fork for a period of time, and to receive merkle proofs for their transactions, for that wrong fork. To complicate this further, the wallet may be using a service for blockchain-related data which also chooses which fork to follow themselves. Unless the wallet can say for which fork they want data, or can explicitly follow the same fork as the service, there is no guarantee that the data they request will be for the right fork.

Services and forks

The wallet may ask the service for the merkle proof for a transaction, and if the transaction is in a block, they will get back the proof for that block. However, if the service is on a different fork the wallet now has two problems.

One source of blockchain state

In the simplest case, your application just uses one stateful blockchain service, a given miner’s MAPI service. You have no way of knowing what fork the service is following, outside of the headers provided in the merkle proofs. This means that if you get a proof notification, you can look at the header in the proof and identify whether they are on a different fork. And if you have already had a proof for the given transaction, it is possible they will send you a further proof if there is a reorg. Since you only have one source of state, you can just locally reorg to the anointed fork of the MAPI service.

Multiple sources of blockchain state

But what happens if you use multiple services, each of which cannot be relied upon to be synchronised to the same fork at the same time? Now you cannot necessarily reorg when you see a service is on a different fork. The application will want to unregister all it’s usage of the service on the wrong fork, and reregister them with the service on the right fork. It would be a lot simpler from an application’s perspective if services followed all viable forks, and you could specify which one you want your state relative to. But this has other problems, like being more likely to result in you not receiving notifications about useful events.

Summing up

This article is about the problems with choosing one fork from multiple viable possibilities, when presenting the application and it’s spendable coins to the user. With the use of services that provide blockchain state to the application, when their choice of fork may differ from that of the applications.

The “early days” disclaimer

The future services, applications and usage of Bitcoin SV are still in development. The best ways to write a service, or features services need to provide for eventual ideal application usage, are not yet clear. Bitcoin SV is the only blockchain aiming to welcome usage, and this requires a lot of work to build out the infrastructure and standards.

Make it someone else’s problem

All these problems go away if you just one of the up and coming wallet as a service solutions. But you get new problems, like their supported use cases may not be a clean union with your desired use cases.

Best practices

It should be very possible to lay out the correct way to follow the right fork, and how to reconcile having been on the wrong fork.

--

--

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