From 7fc41b04580ea32f892be5e224694a42fbfecb76 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jorge=20Tim=C3=B3n?= Date: Tue, 10 Nov 2015 15:19:01 +0100 Subject: fixup! corrections --- bip-0099.mediawiki | 11 +++++------ 1 file 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 @@ 
   BIP: 99
   Title: Motivation and deployment of consensus rule changes ([soft/hard]forks)
-  Author: Jorge Timón [jtimon@jtimon.cc]
+  Author: Jorge Timón 
   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
-- 
cgit v1.2.3