bips/bip-0099.mediawiki

<pre>
  BIP: 99
  Title: Motivation and deployment of consensus rule changes ([soft/hard]forks)
  Authors: Jorge Timón <jtimon@jtimon.cc>
  Status: Closed
  Type: Informational
  Assigned: 2015-06-20
  License: PD
  Discussion: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html
</pre>

==Abstract==

This BIP attempts to create a taxonomy of the different types of
consensus forks and proposes a deployment mechanism for each of them.

==Motivation==

The security assumptions of p2p consensus-based systems like Bitcoin are
not always well-understood, and the best upgrade mechanisms to the
consensus validation rules may vary depending on the type of change being deployed.
Discussing such changes without a uniform view on the deployment
paths often leads to misunderstandings and unnecessarily delays the
deployment of changes.

==Definitions==

;Software fork
: A copy of an existing project. In free software, this can be done without the permission of the original project's maintainers.

;Consensus fork
: A divergence in the implementation of the verification consensus rules can impede the expected eventual convergence of the network in a single chain that has the most proof of work and also satisfies the rules. This can be intentional or be caused by a bug in consensus validation reimplementations.

;Softfork
: A consensus fork wherein everything that was previously invalid remains invalid while blocks that would have previously considered valid become invalid. A hashrate majority of miners can impose the new rules. They have some deployment advantages like backward compatibility.

;Hardfork
: A consensus fork that makes previously invalid blocks valid. Hardforks require all users to upgrade.

;Libconsensus
: a theoretical piece of software that contains the specifications that define the validity of a block for a given state and chain parameters (ie it may act differently on, for example, regtest).

;Libbitcoinconsensus
: the existing implementation is a library that is compiled by default with Bitcoin Core master and exposes a single C function named bitcoinconsensus_verify_script(). Although it has a deterministic build and implements the most complex rules (most of the cryptography, which is itself heavily based on libsecp256k1 after #REPLACE_libsecp256k1_PR), it is still not a complete specification of the consensus rules. Since libconsensus doesn't manage the current state but only the validation of the next block given that state, it is known that this long effort of encapsulation and decoupling will eventually finish, and that the person who moves the last line

==Taxonomy of consensus forks==

===Accidental consensus fork===

Software forks are very different in nature from consensus rules forks. No software
maintainer has special powers over consensus rules changes. There's
many good reasons (experimentation, lack of features, independent
development, diversity, etc) to fork the Bitcoin Core software and it's good
that there's many alternative implementations of the protocol (forks
of Bitcoin Core or written from scratch).

But sometimes a bug in the reimplementation of the consensus
validation rules can prevent users of alternative implementation from
following the longest (most work) valid chain. This can result in
those users losing coins or being defrauded, making reimplementations
of the consensus validation rules very risky. Note that a natural
language specification of those rules doesn't help since the
consensus is not determined by such specification but by the software
that the majority of the network runs. That's why "the implementation
is the specification".

But Bitcoin Core contains many more things than just consensus
validation and it would be unreasonable for all alternative
implementations to depend on it. Bitcoin Core should not be the
specification. That's why the consensus validation is being separated
into a libbitcoinconsensus library with a C API easily accessible from
any language. This makes alternative implementations much more secure
without burdening them with specific design choices made by Bitcoin
Core. It is to be noted that sharing the same code for consensus
validation doesn't prevent alternative implementations from
independently changing their consensus rules: they can always fork
the libbitcoinconsensus project (once it is in a separate repository).

Hopefully libbitcoinconsensus will remove this type of consensus fork
which - being accidental - obviously doesn't need a deployment plan.

====11/12 March 2013 Chain Fork====

There is a precedent of an accidental consensus fork at height 225430.
Without entering into much detail (see <ref name="bip-50">https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki</ref>), the situation was different from
what's being described from the alternative implementation risks (today alternative implementation
still usually rely in different degrees on Bitcoin Core trusted proxies, which
is very reasonable considering the lack of a complete libconsensus).
The two conflicting consensus validation implementations were two
different versions of Bitcoin Core (Bitcoin-qt at the time): 0.8
against all versions prior to it. Most miners had been fast on
upgrading to 0.8 and they were also fast on downgrading to 0.7 as an
emergency when they were asked to by the developers community.

A short summary would be that BDB was being
abandoned in favor of levelDB, and - at the same time - the miner's
policy block size limit was being lift (it was not a consensus rule,
not even enforced via softfork). Even after testing, a case where
levelDB couldn't correctly validate certain bigger blocks only appeared after
deployment in production. Fortunately this was handled very well and
rapidly by the whole worldwide community and nobody is unhappy about
the solution.

But there's some philosophical disagreements on the terms of what the
solution was: we can add a pedantic note on that.
If "the implementation is the specification", then those
levelDB-specific limitations were part of the consensus rules.
Then additional rules were necessary and any alternative
implementation (including 0.8) would have to implement it. Then a
planned consensus fork to migrate all Bitcoin-qt 0.7- users could
remove those additional consensus restrictions.
Had libconsensus being implemented without depending on levelDB,
those additional restrictions wouldn't have been part of "the specification"
and this would just have been a bug in the
consensus rules, just a consensus-critical bug in a set of
implementations, concretely all satoshi-bitcoin-0.7-or-less (which
happened to be a huge super majority of the users), but other
implementations (like libbitcoin) would be free from such bug and
implementing the correct libconsensus specification. But since the
buggy implementation was a super-majority, the solution would have
been to instantly (from a specific block) change the rules to not let
the super-majority deviate from the specification and then have
another consensus fork to remove them. Two theoretical consensus forks