From d954832e3091d3fc61e5d30d14c06f042993134f Mon Sep 17 00:00:00 2001 From: instagibbs Date: Fri, 28 Aug 2015 14:32:58 -0700 Subject: [PATCH 1/7] Random grammar and spelling stuff --- bip-0099.mediawiki | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/bip-0099.mediawiki b/bip-0099.mediawiki index f05247f7..dd1e8bcf 100644 --- a/bip-0099.mediawiki +++ b/bip-0099.mediawiki @@ -16,14 +16,14 @@ 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 +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. Discussing such changes without a uniform view on the deployment paths often leads to misunderstandings and unnecessarily delays the deployment of changes. -==Defintions== +==Definitions== - Software fork: in free software, an existing project can be copied and extended/maintained without permission from the original @@ -35,8 +35,8 @@ deployment of changes. 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. + valid also become invalid. A majority of miners can impose + these kind of changes and they also have some deployment advantages. - Hardfork: an intentional consensus fork that is not a softfork. ==Taxonomy of consensus forks== @@ -51,7 +51,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,7 +78,7 @@ 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 From 1da1397d5427df53c19e72db0116606ebe172ce3 Mon Sep 17 00:00:00 2001 From: Andy Chase Date: Fri, 4 Sep 2015 15:15:08 -0700 Subject: [PATCH 2/7] Bip-99/Add details to definitions --- bip-0099.mediawiki | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-) diff --git a/bip-0099.mediawiki b/bip-0099.mediawiki index dd1e8bcf..040ed450 100644 --- a/bip-0099.mediawiki +++ b/bip-0099.mediawiki @@ -25,19 +25,17 @@ deployment of changes. ==Definitions== -- 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. A majority of miners can impose - these kind of changes and they also have some deployment advantages. -- Hardfork: an intentional consensus fork that is not a softfork. +;Software fork +: A copy of an existing project where management is separate from the existing project. + +;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 +: A change to the Bitcoin protocol wherein previously valid blocks and transactions become invalid. A hashrate majority miners can enforce the new rules so that the change enforced across all clients. Softforks are backward compatible. + +;Hardfork +: A change to the Bitcoin protocol that makes previously invalid blocks valid. Hardforks require all users to upgrade. ==Taxonomy of consensus forks== From 7d31bf365b4e33dad72de0d8ce2fd853947ea737 Mon Sep 17 00:00:00 2001 From: MarcoFalke Date: Mon, 14 Sep 2015 08:43:29 +0200 Subject: [PATCH 3/7] [trivial] typo --- bip-0099.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0099.mediawiki b/bip-0099.mediawiki index 040ed450..1f5fcd7d 100644 --- a/bip-0099.mediawiki +++ b/bip-0099.mediawiki @@ -32,7 +32,7 @@ deployment of changes. : 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 -: A change to the Bitcoin protocol wherein previously valid blocks and transactions become invalid. A hashrate majority miners can enforce the new rules so that the change enforced across all clients. Softforks are backward compatible. +: A change to the Bitcoin protocol wherein previously valid blocks and transactions become invalid. A hashrate majority of miners can enforce the new rules so that the change enforced across all clients. Softforks are backward compatible. ;Hardfork : A change to the Bitcoin protocol that makes previously invalid blocks valid. Hardforks require all users to upgrade. From 82784e60619efca92bc0d6e72c28bfb3df25bbae Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jorge=20Tim=C3=B3n?= Date: Sun, 8 Nov 2015 12:45:35 +0100 Subject: [PATCH 4/7] More corrections and improvements --- bip-0099.mediawiki | 27 ++++++++++++++++----------- 1 file changed, 16 insertions(+), 11 deletions(-) diff --git a/bip-0099.mediawiki b/bip-0099.mediawiki index 1f5fcd7d..eaabd8e2 100644 --- a/bip-0099.mediawiki +++ b/bip-0099.mediawiki @@ -16,9 +16,8 @@ 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. @@ -26,16 +25,22 @@ deployment of changes. ==Definitions== ;Software fork -: A copy of an existing project where management is separate from the existing project. +: 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 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. +: 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 change to the Bitcoin protocol wherein previously valid blocks and transactions become invalid. A hashrate majority of miners can enforce the new rules so that the change enforced across all clients. Softforks are backward compatible. +: 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 change to the Bitcoin protocol that makes previously invalid blocks valid. Hardforks require all users to upgrade. +: 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== @@ -162,7 +167,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...] @@ -191,12 +196,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 @@ -327,7 +332,7 @@ 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, Gregory Sanders, Luke Dashjr, Marco Falke. ==Copyright== From 011fdce88fecc703d639bc0459bacf1ef14bdbc9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jorge=20Tim=C3=B3n?= Date: Sun, 8 Nov 2015 13:19:42 +0100 Subject: [PATCH 5/7] Improvements to Schism hardforks section --- bip-0099.mediawiki | 41 ++++++++++++++++++++++++++++++++++------- 1 file changed, 34 insertions(+), 7 deletions(-) diff --git a/bip-0099.mediawiki b/bip-0099.mediawiki index eaabd8e2..7d0207cf 100644 --- a/bip-0099.mediawiki +++ b/bip-0099.mediawiki @@ -137,27 +137,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 @@ -320,6 +342,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 @@ -332,7 +358,8 @@ https://github.com/freicoin/freicoin/commit/beb2fa54745180d755949470466cbffd1cd6 ==Attribution== -Incorporated corrections and suggestions from: Andy Chase, Bryan Bishop, Btcdrak, Gregory Sanders, Luke Dashjr, Marco Falke. +Incorporated corrections and suggestions from: Andy Chase, Bryan Bishop, +Btcdrak, Gavin Andresen, Gregory Sanders, Luke Dashjr, Marco Falke. ==Copyright== From f0848435d9ce6eeeeaa9d3402dfb1e6d9f3f1ec8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jorge=20Tim=C3=B3n?= Date: Sun, 8 Nov 2015 13:23:16 +0100 Subject: [PATCH 6/7] Add bip99 to readme --- README.mediawiki | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/README.mediawiki b/README.mediawiki index 7c879024..de82c206 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 From 7fc41b04580ea32f892be5e224694a42fbfecb76 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jorge=20Tim=C3=B3n?= Date: Tue, 10 Nov 2015 15:19:01 +0100 Subject: [PATCH 7/7] fixup! corrections --- bip-0099.mediawiki | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/bip-0099.mediawiki b/bip-0099.mediawiki index 7d0207cf..c40bacb6 100644 --- a/bip-0099.mediawiki +++ b/bip-0099.mediawiki @@ -1,7 +1,7 @@ 
   BIP: 99
   Title: Motivation and deployment of consensus rule changes ([soft/hard]forks)
-  Author: Jorge Timón [jtimon@jtimon.cc]
+  Author: Jorge Timón 
   Status: Draft
   Type: Informational | Process
   Created: 2015-06-20
@@ -84,13 +84,12 @@ There is a precedent of an accidental consensus fork at height 225430.
 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
@@ -110,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