summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJorge Timón <jtimon@jtimon.cc>2015-11-10 15:19:01 +0100
committerJorge Timón <jtimon@jtimon.cc>2015-11-10 15:19:01 +0100
commit7fc41b04580ea32f892be5e224694a42fbfecb76 (patch)
tree1c2671ad77bb2fe816697284a2e1c6c8ccc92137
parentf0848435d9ce6eeeeaa9d3402dfb1e6d9f3f1ec8 (diff)
downloadbips-7fc41b04580ea32f892be5e224694a42fbfecb76.tar.xz
fixup! corrections
-rw-r--r--bip-0099.mediawiki11
1 files changed, 5 insertions, 6 deletions
diff --git a/bip-0099.mediawiki b/bip-0099.mediawiki
index 7d0207c..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
@@ -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