diff options
| author | Jorge Timón <jtimon@jtimon.cc> | 2015-11-10 15:19:01 +0100 |
|---|---|---|
| committer | Jorge Timón <jtimon@jtimon.cc> | 2015-11-10 15:19:01 +0100 |
| commit | 7fc41b04580ea32f892be5e224694a42fbfecb76 (patch) | |
| tree | 1c2671ad77bb2fe816697284a2e1c6c8ccc92137 /bip-0099.mediawiki | |
| parent | f0848435d9ce6eeeeaa9d3402dfb1e6d9f3f1ec8 (diff) | |
fixup! corrections
Diffstat (limited to 'bip-0099.mediawiki')
| -rw-r--r-- | bip-0099.mediawiki | 11 |
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 |