Adding a section to Operations: Fork management and contingency planning

[TaulantRamabaja]

Hi Guys

At Bitsapphire we've been taking a look at CCSS. Looks like it will be our go to document from now on.

I wasn't able to find anything on fork management and contingency planning. We think every institution utilizing Bitcoin requires such contingency plans.

Example procedures could include:

• Transactions should not be processed by your full node if a 3 level deep fork is detected. This should lead to an automatic freeze that requires manual override.
• Running full nodes with different software (be that versions or different projects). If their block history don't match assume a fork and revert to using the version most used by the network at the time.

[Abstrct]

Hi @TaulantRamabaja,

It's always great to hear about other organizations using the standard internally. Even better when they reach out to contribute! Thanks for taking the time.

The topic of actually monitoring blockchain health is taking place over here: #15
Please give that a read and let us know your thoughts on the matter there.

Outside of that though, dealing with the results of that monitoring hasn't been discussed yet and really should be.

Just like we have the Key Compromise Protocol, there may be another set of documentation we require organizations to have regarding what to do in the event of specific blockchain states. This could cover concepts such as:

• Confirmation Requirements
• What to do when a small 1 or 2 block fork has occurred (process normally, process but halt outgoing transactions, halt momentarily)
• How to roll back non-blockhain system state as it relates to the blockchain changes
• What to do when a massive fork has occurred (halt all systems, display status messages to users, etc)

Of course, some of these specifics could be prescribed as well, especially in the case of a Level 3 system, but a coffee shop accepting bitcoin may need to be less concerned with forks than an exchange or gaming site so we would want to keep that in mind.

[CodeShark]

Confirmation counts are really a measure of irreversibility of a transaction. If there's a fork two blocks deep and my transaction is in the last block both chains share, you can almost treat the transaction as if it has three confirmations since the amount of work required to reverse it is three blocks. If it's in only one of the two forks, it should be treated as unconfirmed until the fork it's in wins overwhelmingly on the network.

Some people are currently working on modifications to the terminology for confirmations to make the concept more clear, especially to newcomers. For instance, bitcoin-dot-org/Bitcoin.org#974

I think this topic probably deserves its own thread.

[ronaldstoner]

In my opinion - this may be better listed as a "caveat" in the CCSS. The controls in the CCSS deal with the generation, control, and security of keys. Due to the nature of forks, and how they may affect and information system, it may be hard to write a binary control due to unknown limitations, features, etc.

There is also the issue of soft versus hard forks, and systems that chose to implement the fork versus those that do not. If controls are to be written, they need to apply in a way that is applicable to all systems.

[jlopp]

The complexities of handling forks can't be easily distilled into a point by point guide, IMO. Each fork needs to be researched to understand the implications of using keys that are valid on multiple forks.