More corrections and improvements

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==