fixup! corrections

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