diff options
| -rw-r--r-- | bip-0099.mediawiki | 27 |
1 files changed, 16 insertions, 11 deletions
diff --git a/bip-0099.mediawiki b/bip-0099.mediawiki index 1f5fcd7..eaabd8e 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== |