Remove trailing whitespace from all BIPs

1 files changed, 14 insertions, 14 deletions

diff --git a/bip-0099.mediawiki b/bip-0099.mediawiki
index 156eec0..5368b53 100644
--- a/bip-0099.mediawiki
+++ b/bip-0099.mediawiki
@@ -23,7 +23,7 @@ not always well-understood, and the best upgrade mechanisms to the
 consensus validation rules may vary depending on the type of change being deployed.
 Discussing such changes without a uniform view on the deployment
 paths often leads to misunderstandings and unnecessarily delays the
-deployment of changes. 
+deployment of changes.
 
 ==Definitions==
 
@@ -43,7 +43,7 @@ deployment of changes.
 : a theoretical piece of software that contains the specifications that define the validity of a block for a given state and chain parameters (ie it may act differently on, for example, regtest).
 
 ;Libbitcoinconsensus
-: the existing implementation is a library that is compiled by default with Bitcoin Core master and exposes a single C function named bitcoinconsensus_verify_script(). Although it has a deterministic build and implements the most complex rules (most of the cryptography, which is itself heavily based on libsecp256k1 after #REPLACE_libsecp256k1_PR), it is still not a complete specification of the consensus rules. Since libconsensus doesn't manage the current state but only the validation of the next block given that state, it is known that this long effort of encapsulation and decoupling will eventually finish, and that the person who moves the last line 
+: the existing implementation is a library that is compiled by default with Bitcoin Core master and exposes a single C function named bitcoinconsensus_verify_script(). Although it has a deterministic build and implements the most complex rules (most of the cryptography, which is itself heavily based on libsecp256k1 after #REPLACE_libsecp256k1_PR), it is still not a complete specification of the consensus rules. Since libconsensus doesn't manage the current state but only the validation of the next block given that state, it is known that this long effort of encapsulation and decoupling will eventually finish, and that the person who moves the last line
 
 ==Taxonomy of consensus forks==
 
@@ -76,14 +76,14 @@ without burdening them with specific design choices made by Bitcoin
 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). 
+the libbitcoinconsensus project (once it is in a separate repository).
 
 Hopefully libbitcoinconsensus will remove this type of consensus fork
 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. 
+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
@@ -104,7 +104,7 @@ rapidly by the whole worldwide community and nobody is unhappy about
 the solution.
 
 But there's some philosophical disagreements on the terms of what the
-solution was: we can add a pedantic note on that.   
+solution was: we can add a pedantic note on that.
 If "the implementation is the specification", then those
 levelDB-specific limitations were part of the consensus rules.
 Then additional rules were necessary and any alternative
@@ -126,7 +126,7 @@ another consensus fork to remove them. Two theoretical consensus forks
 instead of one but the first one deployed practically for free. The
 practical result would have been identical and only the definitions
 change. This means discussing something that went uncontroversially
-well further is "philosophical bike-shed" (TM).  
+well further is "philosophical bike-shed" (TM).
 
 ===Unilateral softforks===
 
@@ -157,17 +157,17 @@ that this must always be the case.
 While 2 chains cohexist, they can be considered two different
 currencies.
 We could say that bitcoin becomes bitcoinA and bitcoinB. The implications for market
-capitalization are completely unpredictable, 
+capitalization are completely unpredictable,
 
-maybe mc(bitcoinA) = mc(bitcoinB) = mc(old_bitcoin), 
+maybe mc(bitcoinA) = mc(bitcoinB) = mc(old_bitcoin),
 
-maybe mc(bitcoinA) + mc(bitcoinB) = mc(old_bitcoin), 
+maybe mc(bitcoinA) + mc(bitcoinB) = mc(old_bitcoin),
 
 maybe mc(bitcoinA) + mc(bitcoinB) = 1000 * mc(old_bitcoin),
 
 maybe mc(bitcoinA) + mc(bitcoinB) = 0,
 
-... 
+...
 
 Schism hardforks have been compared to one type of altcoins called
 "spinoffs"[spinoffs] that distribute all or part of its initial seigniorage to
@@ -224,7 +224,7 @@ Let's imagine BIP66 had a crypto backdoor
 that nobody noticed and allows an evil developer cabal to steal
 everyone's coins. The users and non-evil developers could join, fork
 libconsensus and use the forked version in their respective bitcoin
-implementations. 
+implementations.
 Should miner's "vote" be required to express their consent? What if some miners
 are part of the cabal? In the unlikely event that most miners are
 part of such an evil cabal, changing the pow function may be
@@ -268,7 +268,7 @@ that's why the voting mechanism and first used for BIP30 and BIP66.
 The current voting threshold for softfork enforcement is 95%. There's
 also a 75% threshold for miners to activate it as a policy rule, but
 it should be safe for miners to activate such a policy from the start
-or later than 75%, as long as they enforce it as consensus rule after 95%. 
+or later than 75%, as long as they enforce it as consensus rule after 95%.
 
 The current miners' voting mechanism can be modified to allow for
 changes to be deployed in parallel, the rejection of a concrete
@@ -355,12 +355,12 @@ worth of blocks).
 [5] Original references:
 https://bitcointalk.org/index.php?topic=114751.0
 https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772
-Rebased patch: 
+Rebased patch:
 https://github.com/freicoin/freicoin/commit/beb2fa54745180d755949470466cbffd1cd6ff14
 
 ==Attribution==
 
-Incorporated corrections and suggestions from: Andy Chase, Bryan Bishop, 
+Incorporated corrections and suggestions from: Andy Chase, Bryan Bishop,
 Btcdrak, Gavin Andresen, Gregory Sanders, Luke Dashjr, Marco Falke.
 
 ==Copyright==