bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-05-12 12:03:29 +00:00
Code Issues Releases Wiki Activity

fixup! corrections

Browse Source
This commit is contained in:
Jorge Timón 2015-11-10 15:19:01 +01:00
parent f0848435d9
commit 7fc41b0458
1 changed files with 5 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
bip-0099.mediawiki
View File

@ -1,7 +1,7 @@
<pre> <pre>
BIP: 99 BIP: 99
Title: Motivation and deployment of consensus rule changes ([soft/hard]forks) 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 Status: Draft
Type: Informational | Process Type: Informational | Process
Created: 2015-06-20 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 Without entering into much detail (see [2]), the situation was different from
what's being described from the alternative implementation risks (today alternative implementation what's being described from the alternative implementation risks (today alternative implementation
still usually rely in different degrees on Bitcoin Core trusted proxies, which still usually rely in different degrees on Bitcoin Core trusted proxies, which
is very reasonable considering the lack of a complete is very reasonable considering the lack of a complete libconsensus).
libbitcoinsensus).
The two conflicting consensus validation implementations were two The two conflicting consensus validation implementations were two
different versions of Bitcoin Core (Bitcoin-qt at the time): 0.8 different versions of Bitcoin Core (Bitcoin-qt at the time): 0.8
against all versions prior to it. Most miners had been fast on 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 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 A short summary would be that BDB was being
abandoned in favor of levelDB, and - at the same time - the miner's 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 planned consensus fork to migrate all Bitcoin-qt 0.7- users could
remove those additional consensus restrictions. remove those additional consensus restrictions.
Had libconsensus being implemented without depending on levelDB, Had libconsensus being implemented without depending on levelDB,
those additional restrictions wouldn't have been "the implementation those additional restrictions wouldn't have been part of "the specification"
is the specification" and this would just have been a bug in the and this would just have been a bug in the
consensus rules, just a consensus-critical bug in a set of consensus rules, just a consensus-critical bug in a set of
implementations, concretely all satoshi-bitcoin-0.7-or-less (which implementations, concretely all satoshi-bitcoin-0.7-or-less (which
happened to be a huge super majority of the users), but other happened to be a huge super majority of the users), but other