Merge pull request #237 from jtimon/bip99-2

Bip99: Improvements

2 files changed, 71 insertions, 36 deletions

diff --git a/README.mediawiki b/README.mediawiki
index 7c87902..de82c20 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -302,6 +302,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
+| [[bip-0099.mediawiki|99]]
+| Motivation and deployment of consensus rule changes
+| Jorge Timón
+| Informational | Process
+| Draft
+|-
 | [[bip-0101.mediawiki|101]]
 | Increase maximum block size
 | Gavin Andresen
diff --git a/bip-0099.mediawiki b/bip-0099.mediawiki
index f05247f..c40bacb 100644
--- a/bip-0099.mediawiki
+++ b/bip-0099.mediawiki
@@ -1,7 +1,7 @@
 <pre>
   BIP: 99
   Title: Motivation and deployment of consensus rule changes ([soft/hard]forks)
-  Author: Jorge Timón [jtimon@jtimon.cc]
+  Author: Jorge Timón <jtimon@jtimon.cc>
   Status: Draft
   Type: Informational | Process
   Created: 2015-06-20
@@ -16,28 +16,31 @@ 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 upgrade mechanisms to the
-consensus rules are a work in progress that may vary depending on the
-type of change being deployed.
+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. 
 
-==Defintions==
-
-- Software fork: in free software, an existing project can be copied
-  and extended/maintained without permission from the original
-  project's maintainers.
-- Consensus fork: a divergence in the implementation of the
-  verification 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: an intentional consensus fork where everything that
-  was previously invalid remains invalid, but some things that were
-  valid also become invalid. Majority of miners can impose
-  this kind of changes and they also have some deployment advantages.
-- Hardfork: an intentional consensus fork that is not a softfork.
+==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==
 
@@ -51,7 +54,7 @@ that there's many alternative implementations of the protocol (forks
 of Bitcoin Core or written from scratch).
 
 But sometimes a bug in the reimplementaion of the consensus
-validation rules can prevent alternative implementation users from
+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
@@ -78,16 +81,15 @@ 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 in much detail (see [2]), the situation was different from
+Without entering into much detail (see [2]), 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
-libbitcoinsensus).
+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 ask to by the developers community.
+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
@@ -107,8 +109,8 @@ 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 "the implementation
-is the specification" and this would just have been a bug in the
+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
@@ -134,27 +136,49 @@ consider the risk of motivating a schism hardfork before attempting
 such a consensus fork. A deployment plan for this case is also
 unnecessary.
 
-===Schism[1] hardforks===
+===Schism hardforks===
 
-In all of the following examples there's clearly a confrontation that
-is being resolved using an intentional consensus fork.
+Fundamental disagreements and controversies are part of social
+systems, like the one defined as the human participants in the Bitcoin
+network. Without judging the motivation of the rule discrepancies or
+what rules were in place first, we're definining schism[1] hardforks as
+those in which - for whatever reason - users are consiously going to validate 2
+different sets of consensus rules. Since they will validate different
+rulesets, they will end up following 2 different chains for at least
+some time, maybe forever.
 
-Being a schism hardfork, there will likely be 2 chains
-coexisting for at least some time, maybe forever. Maybe bitcoin
-becomes bitcoinA and bitcoinB. The implications for market
+One possible result observed in the past[non_proportional_inflatacoin_fork]
+is that one of the chains rapidly disappears, but nothing indicates
+that this must always be the case.
+
+While 2 chains cohexist, they can be considered two different
+currencies.
+We could say that bitcoin becomes bitcoinA and bitcoinB. The implications for market
 capitalization are completely unpredictable, 
+
 maybe mc(bitcoinA) = mc(bitcoinB) = mc(old_bitcoin), 
+
 maybe mc(bitcoinA) + mc(bitcoinB) = mc(old_bitcoin), 
+
 maybe mc(bitcoinA) + mc(bitcoinB) = 1000 * mc(old_bitcoin),
+
 maybe mc(bitcoinA) + mc(bitcoinB) = 0,
+
 ... 
 
+Schism hardforks have been compared to one type of altcoins called
+"spinoffs"[spinoffs] that distribute all or part of its initial seigniorage to
+bitcoin owners at a given block height.
+
 This is very disruptive and hopefully will never be needed. But if
 it's needed the best deployment path is just to activate the rule
 changes after certain block height in the future. On the other hand,
 it is healthy decentralization-wise that many independent software
 projects are ready to deploy a schism hardfork.
 
+In all of the following examples there's clearly a confrontation that
+is being resolved using an intentional consensus hardfork.
+
 ====ASIC-reset hardfork====
 
 Imagine ASIC production has been consolidated to a single company and
@@ -164,7 +188,7 @@ mine itself. For that or another reason, a single entity controls
 improvement in decentralization. Such an untenable centralization could
 be fixed (with great risks) by switching the hash function used in the
 proof of work, effectively "pressing the restart button" on the ASIC
-market. [The next function should be simple to implement in ASIC as
+market. The next function should be simple to implement in ASIC as
 well so that the market can more easily develop as a healthy and
 competitive one (as opposed to what the "ASIC-hard" proponents would
 want), but that's another story...]
@@ -193,12 +217,12 @@ have to be ignored.
 
 ====Anti-cabal hardfork====
 
-Let's imagine BIP66 [TODO remove has been deployed, but it] had a crypto backdoor
+Let's imagine BIP66 had a crypto backdoor
 that nobody noticed and allows an evil developer cabal to steal
 everyone's coins. The users and non-evil developers could join, fork
 libconsensus and use the forked version in their respective bitcoin
 implementations. 
-Should miner's "vote" to express their consent? What if some miners
+Should miner's "vote" be required to express their consent? What if some miners
 are part of the cabal? In the unlikely event that most miners are
 part of such an evil cabal, changing the pow function may be
 required. In other cases, mining "vote" doesn't have much value
@@ -317,6 +341,10 @@ worth of blocks).
 
 [2] https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki
 
+[non_proportional_inflatacoin_fork] TODO missing link
+
+[spinoffs] https://bitcointalk.org/index.php?topic=563972.0
+
 [3] https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
 
 [4] https://github.com/bitcoin/bitcoin/compare/0.11...jtimon:hardfork-timewarp-0.11
@@ -329,7 +357,8 @@ https://github.com/freicoin/freicoin/commit/beb2fa54745180d755949470466cbffd1cd6
 
 ==Attribution==
 
-Incorporated corrections and suggestions from: btcdrak, Andy Chase, Bryan Bishops, Luke Dashjr
+Incorporated corrections and suggestions from: Andy Chase, Bryan Bishop, 
+Btcdrak, Gavin Andresen, Gregory Sanders, Luke Dashjr, Marco Falke.
 
 ==Copyright==