My take on the Bitcoin Testnet Fork

Bitcoin Unlimited signals compatibility with BIP109 because it accepts a superset of what BIP109 allows.  It accepts larger blocks and more signature operations.  So essentially BIP109 is a "soft fork" of what Unlimited is capable of.  Unfortunately there is no way to signal that a client supports a superset of BIP109, so a choice of 2 imperfect alternatives had to be made.  In the context of the 1MB limit and BU having ability to produce these superset blocks, it made sense to signal BIP109 support.  At the same time, there is a passed BUIP that covers strict BIP109 support that can be quickly implemented at need.

On testnet, Bitcoin Unlimited has the mining majority and an ~600k transaction was created that exceeded the BIP109 signature checking restrictions.  Bitcoin Unlimited included it in a block and so clients that strictly adhere to BIP109 were forked (Bitcoin Classic).  Bitcoin Unlimited could have avoided this problem by following our philosophy to be conservative in what is generated but liberal in what is accepted.

However, this event is very instructive in regards to the role of consensus in the network.  In short, there is none.  Bitcoin is founded on the principle of zero-trust.  If we rely on developers to produce perfect and compatible software, we are re-introducing trust.  And then the difference between Bitcoin and traditional financial networks becomes merely a difference in flavor (who do you trust) not a fundamental new concept.  We now see this in Ethereum -- the Ethereum developers have chosen to be the arbiters of their network and participants must now trust these developers to accept the participant's transactions.

It should be instructive to note that Bitcoin Unlimited is unaffected by the situation.  And it also would be unaffected if the roles were reversed (if Bitcoin Unlimited was the minority hash-rate and a minor rule was being broken).

Ask yourself why do you perceive it to be "bad" that Classic forked from the network?  I believe that it is "bad" because the rule that was broken was not important enough to warrant a fork.  Classic users would have preferred to follow the most-work chain and ignore this rule.

But what if a client produced a 100 coin coinbase transaction?  Would you prefer that your client follow this chain or fork?

From a zero trust, game theory perspective a client should follow the chain that maximizes the value of the coins owned by the user.  Therefore a client should only choose to fork when a rule change occurs that reduces the value of the user's coins.  From this observation, one can distill a minimum set of rules -- rules that are absolutely essential to protect the "money function" of Bitcoin.

Bitcoin Unlimited's "excessive block" and "excessive accept depth" algorithm is not just and arbitrary choice -- its the optimal choice rational software can make in an untrusted network.  In essence, it encourages the client's preferences to the extent that the client can do so, but then follows the majority when the client's preference is rejected.

So Bitcoin Unlimited follows a philosophy of following the most-work chain unless a block breaks the "money function rules" -- increasing inflation, spending other user's coins, etc.  All of these activities will undermine the value of the user's own coins and in that situation, a fork may preserve that value since the value of the rule may be greater than value added by having the highest difficulty chain.

To date, Bitcoin has been sheltered by having a single-client (trust-the-developers) implementation but for the last year the massive liability of this approach has become evident in the inability of that client to deliver the growth that Bitcoin so desperately needs.  As we move into a trustless, multi-client environment, Bitcoin client developers will have to ask themselves "how important are these rules, and what should my client do if the mining majority breaks them?"