Some of kanzure's nits, copyright, updated Attribution, don't repeat "Without entering in much detail"

1 files changed, 20 insertions, 17 deletions

diff --git a/bip-0099.mediawiki b/bip-0099.mediawiki
index 0e41870..f05247f 100644
--- a/bip-0099.mediawiki
+++ b/bip-0099.mediawiki
@@ -46,9 +46,9 @@ deployment of changes.
 Software forks are very different in nature from consensus rules forks. No software
 maintainer has special powers over consensus rules changes. There's
 many good reasons (experimentation, lack of features, independent
-development, diversity, etc) to fork the Bitcoin core software and it's good
+development, diversity, etc) to fork the Bitcoin Core software and it's good
 that there's many alternative implementations of the protocol (forks
-of Bitcoin core or written from scratch).
+of Bitcoin Core or written from scratch).
 
 But sometimes a bug in the reimplementaion of the consensus
 validation rules can prevent alternative implementation users from
@@ -60,36 +60,36 @@ consensus is not determined by such specification but by the software
 that the majority of the network runs. That's why "the implementation
 is the specification".
 
-But Bitcoin core contains many more things than just consensus
+But Bitcoin Core contains many more things than just consensus
 validation and it would be unreasonable for all alternative
-implementations to depend on it. Bitcoin core should not be the
+implementations to depend on it. Bitcoin Core should not be the
 specification. That's why the consensus validation is being separated
 into a libbitcoinconsensus library with a C API easily accessible from
 any language. This makes alternative implementations much more secure
 without burdening them with specific design choices made by Bitcoin
-core. It is to be noted that sharing the same code for consensus
+Core. It is to be noted that sharing the same code for consensus
 validation doesn't prevent alternative implementations from
 independently changing their consensus rules: they can always fork
 the libbitcoinconsensus project (once it is in a separate repository). 
 
 Hopefully libbitcoinconsensus will remove this type of consensus fork
-which - being accidental - obviously don't need a deployment plan.
+which - being accidental - obviously doesn't need a deployment plan.
 
 ====11/12 March 2013 Chain Fork====
 
 There is a precedent of an accidental consensus fork at height 225430. 
-Without entering in much detail, the situation was different from
+Without entering in 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
+still usually rely in different degrees on Bitcoin Core trusted proxies, which
 is very reasonable considering the lack of a complete
 libbitcoinsensus).
 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
 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.
 
-Without entering in much detail[2], the issue was 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
 policy block size limit was being lift (it was not a consensus rule,
 not even enforced via softfork). Even after testing, a case where
@@ -207,7 +207,7 @@ uncontroversial anyway.
 
 ===Uncontroversial consensus upgrades===
 
-"Uncontroversial" is something though to define in this context. What
+"Uncontroversial" is something tough to define in this context. What
 if a single user decides he won't upgrade no matter what and
 he doesn't even attempt to explain his decision? Obviously, such
 a user should be just ignored. But what if the circumstances are
@@ -302,7 +302,7 @@ The chosen consensus change is the fix of the timewarp attack
 discovered and also fixed with a simple patch[5] by @ArtForz. This
 change has been deployed by most altcoins that made any minimally
 meaningful change to bitcoin and thus can be considered somewhat
-tested (in fact, most SHA256d altcoins that didn't implemented it have
+tested (in fact, most SHA256d altcoins that didn't implement it have
 died or being forced to implement it as an emergency hardfork). When
 deploying this change has been discussed, usually arguments in the
 lines of "if we get to the point when this matters to bitcoin, we
@@ -311,17 +311,13 @@ shouldn't be seen as a disadvantage in this context, since it means we
 can safely activate the fix very far away in the future (say, 4 years
 worth of blocks).
 
-==Attribution==
-
-Incorporated suggestions from @btcdrak.
-
 ==Footnotes==
 
 [1] https://en.wikipedia.org/wiki/Schism
 
 [2] https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki
 
-[3] http://sourceforge.net/p/bitcoin/mailman/message/34146741/ 
+[3] https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
 
 [4] https://github.com/bitcoin/bitcoin/compare/0.11...jtimon:hardfork-timewarp-0.11
 
@@ -331,3 +327,10 @@ https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772
 Rebased patch: 
 https://github.com/freicoin/freicoin/commit/beb2fa54745180d755949470466cbffd1cd6ff14
 
+==Attribution==
+
+Incorporated corrections and suggestions from: btcdrak, Andy Chase, Bryan Bishops, Luke Dashjr
+
+==Copyright==
+
+This document is placed in the public domain.