# Last edited on 2015-08-13 13:03:47 by stolfilocal
# NOT POSTED YET

Accordingto the bitcoin protocol, all players must look for the blockchain that consists entirely of *valid* blocks and has the most proof-of-work.  The *consensus rules* of bitcoin are the rules that define when a block is valid.  Some rules can be checked by looking only at one block in isolation. For example, every input of every transaction in the block must have a cryptographic signature taht is valid for the corresponding address. Other rules require looking at all the previous blocks, or at some subset of them. For example, one of the rules is that the parent block, whose hash is included in the block's header, must be itself valid; and so on recursively for the whole blockchain.  Another rule is that any input of any transaction must be an output of some previosu transaction, which as hot been used by any other transaction between the two.  To check whether the block has enough proof of work, the timestamps in the previous blocks (up to 4199 of them) may have to be checked, to determine the difficulty required at that time.  Some rules only apply after a certain block number; or after a *blockchain voting event* -- the first sequence of N consecutive blocks that contains M blocks with a specified **version** tag; or after K blocks following such an event.

Occasionally, the consensus rules must be modified -- to improve some aspect of the system, to remove bugs as they are discovered, to adapt to changing economic conditions, etc..  Usually, the changes are only proactive, that is, are scheduled to apply only after some future block; before that block, the new rules coincide with the old ones.  However, the change sometimes is *slightly retroactive* in that it is declared to apply starting at some past block.  That is, the last N blocks, valid by the old rules, are considered invalid, and must be rebuilt and re-mined acording to the new rules.

In the bitcoin developer folklore, as put out in the Bitcoin Wiki, changes to the consensus rules can be of two types: *soft forks* and *hard forks*, depending on whether the changes make the rules more restrictive or more liberal, respectively.  Soft forks are supposed to be relatively benign, while hard forks are teribly dangerous things -- like mini black holes covered in radioactive smallpox, or lab glassware in Texas.  

In my understanding, this classification is incomplete and misleading, because both types of forks are malign, and there are more flavors of forks -- including the type that should be used in lieu of them.

Both hard and soft forks are called "forks" because they can result in a split of the blockchain, and hence of the coin.  But they are basically the same: they differ only on how the fork starts, but once started they may evolve in the same ways.

In both types of fork, there are two versions of the software, vP (the more permissive one) and vR (the more restrictive one).  Once someone mines a block BP(N) that is valid according to version vP of the rules, but invalid according to version vR, the blockchain splits: players running vP will accept BP(N) and any other mined on top of it as valid, while fully-checking players running vR will reject BP(N) and wait for some alternative BR(N) that is valid by their rules, and mine another branch on top of that.   

If the vR validity rules are simply a restriction of the vP ones, vP players will consider both braches valid and will choose among them by their length; whereas the full-checking vR players will consider only the vR branch valid, whatever the lengths.  Then:

> **State Ⓐ**: if vP has more hashpower than vR, the vP branch will tend to grow faster than the vR branch.  The coin will then split.   The miners running vP software will extend only the vP branch, while the vR miners will extend only the vR branch.  

> In this 'split-chain' state Ⓐ, all vP clients will consider only the vP branch, and full vR clients will consider only the vR branch.  However, if transactions are not version-tagged, the clients will have no control of which branch(es) will include them.  Moreover, lazy vR clients, that do not check the entire chain, may get confused and take the vP chain as true, because it is longer, not realizing that it is invalid by their chosen rules.  The inconsistency may confuse those clients, and cause them to fail in arbitrary ways.

> **State Ⓑ:** if vR has more hashpower than vP, the vR branch will tend to grow faster than the vP branch.  By luck, the vP miners may succeed at mining another block BP(N+1) on top of B(N); and maybe a few more.  Even if those blocks are vR-valid by themselves, they will be ignored by careful vR players, for being connected to a vR-invalid block.  However, as soon as the vR branch gets ahead, the vP miners will abandon those blocks and switch to  extend the vR branch, too.

> Now and then, the vP miners will mine another block that is vR-invalid; and then the chain will fork again.  So the chain will be continually splitting off side branches, that start with a vP-valid but vR-invalid block, and die after a few blocks.  The frequency of these branches depends on the relative hashpower fractions, and on the rarity of vP-but-not-vR blocks.   

> In this 'stuttering' state Ⓑ, full clients running vR will not notice any problem; but clients running vP, and lazy vR clients, will see frequent stutterings of the blockchain, and had better wait for several confirmations -- especially if the hashpower fractions are close to 50% each.  

The same situation will hold, with swapped labels, if the rules of vP are merely a restriction of those of vR.  

Note that, in this situation (one version is just a restriction of the other) it is not relevant which version is 'new' and which is 'original' (which is the usual criterion to distinguish 'soft' and 'hard' forks).  In other words, before the block when the change is supposed to start, the two versions of the rules must have identical outcomes; but it does not matter whether they are both vP, both vR, or some other set of rules entirely.   What matters is which version has the more hashpower.  

How will these states evolve?  Normally, if the system gets into the 'stuttering' state Ⓑ, the minority miners running vP may get tired of the frequent orphans, and switch to the majority version vR.  If all of them switch, vP will die and vR will be "the" bitcoin. Neither the vP nor the vR clients will notice anything.  In particular, the vP clients will not have to switch, although that may leave them slighltly less secure in theory (since they are noy checling the extra rules that distinguish vR from vP). 

However, if the system is in state  Ⓑ it could happen that the vP miners persist, and enough vR miners switch to vP for the latter to become majority, and the system will be in state Ⓐ.  

If the system is the 'split chain' state Ⓐ, and all minority vR miners decide to switch to vP, then the vR branch will die.  Clients running vP will not notice anything.  Full vR clients will notice that the vR chain died, and will presumably switch to vP.  Lazy vR clients will not notice anything, but will be using a chain that is actually vR-invalid, but assuming that it is vR-valid.  That may cause the client to get confused and fail in arbitrary ways.  Conversely, if the system is in state  Ⓐ, and some vP miners switch to vR, the state would change to Ⓑ.  

Thus, instead of 'soft fork' I prefer to call that a 'gooey sticky mushy fork' -- because, no matter whether it starts in situation Ⓐ or Ⓑ, it will be messy for the lazy SPV clients, and also for full vP clients until the vP chain dies.  This is the outcome that developers hope, when they decide to do a soft fork (replace the current version vP by a more restrictive one vR). 

There is another case, when neither version is a restriction of the other, but only rarely does a block arise that is valid for only one of them.  Yet another variant occurs when vP accepts as valid all vR-valid blocks, but *never* generates a vR-valid block itself.

<<< Version tagging of transactions and network split.

<<< Option for soft fork rather than clean fork is typical hacker style: opt for a complicated solution that only hackers can understand, attempting to hide detail from "dumb people" because they they might get upset, but in the end causing more distress and accidents than the simpled drastic option.  It is the same reason why they prefer complicated dynamic algorithms for the block size limit, triggered by impersonal blockchain voting without the clients knowing, rather than publicly announced fork dates and getting the approval of major players by talking to them.