Remove trailing whitespace from all BIPs

bip-0009.mediawiki

@@ -119,7 +119,7 @@ other one simultaneously transitions to STARTED, which would mean both would dem
 
 Note that a block's state never depends on its own nVersion; only on that of its ancestors.
 
-        case STARTED: 
+        case STARTED:
             if (GetMedianTimePast(block.parent) >= timeout) {
                 return FAILED;
             }

bip-0017.mediawiki

@@ -86,7 +86,7 @@ Avoiding a block-chain split by malicious pay-to-script transactions requires ca
 
 * A pay-to-script-hash transaction that is invalid for new clients/miners but valid for old clients/miners.
 
-To gracefully upgrade and ensure no long-lasting block-chain split occurs, more than 50% of miners must support full validation of the new transaction type and must switch from the old validation rules to the new rules at the same time. 
+To gracefully upgrade and ensure no long-lasting block-chain split occurs, more than 50% of miners must support full validation of the new transaction type and must switch from the old validation rules to the new rules at the same time.
 
 To judge whether or not more than 50% of hashing power supports this BIP, miners are asked to upgrade their software and put the string "p2sh/CHV" in the input of the coinbase transaction for blocks that they create.
 

bip-0038.mediawiki

@@ -64,7 +64,7 @@ To keep the size of the encrypted key down, no initialization vectors (IVs) are
 * How the user sees it: 58 characters always starting with '6P'
 ** Visual cues are present in the third character for visually identifying the EC-multiply and compress flag.
 * Count of payload bytes (beyond prefix): 37
-** 1 byte (''flagbyte''): 
+** 1 byte (''flagbyte''):
 *** the most significant two bits are set as follows to preserve the visibility of the compression flag in the prefix, as well as to keep the payload within the range of allowable values that keep the "6P" prefix intact.  For non-EC-multiplied keys, the bits are 11.  For EC-multiplied keys, the bits are 00.
 *** the bit with value 0x20 when set indicates the key should be converted to a base58check encoded P2PKH bitcoin address using the DER compressed public key format. When not set, it should be a base58check encoded P2PKH bitcoin address using the DER uncompressed public key format.
 *** the bits with values 0x10 and 0x08 are reserved for a future specification that contemplates using multisig as a way to combine the factors such that parties in possession of the separate factors can independently sign a proposed transaction without requiring that any party possess both factors.  These bits must be 0 to comply with this version of the specification.
@@ -75,10 +75,10 @@ To keep the size of the encrypted key down, no initialization vectors (IVs) are
 **16 bytes: lasthalf: An AES-encrypted key material record (contents depend on whether EC multiplication is used)
 * Range in base58check encoding for non-EC-multiplied keys without compression (prefix 6PR):
 ** Minimum value: 6PRHv1jg1ytiE4kT2QtrUz8gEjMQghZDWg1FuxjdYDzjUkcJeGdFj9q9Vi (based on 01 42 C0 plus thirty-six 00's)
-** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's) 
+** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's)
 * Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6PY):
 ** Minimum value: 6PYJxKpVnkXUsnZAfD2B5ZsZafJYNp4ezQQeCjs39494qUUXLnXijLx6LG (based on 01 42 E0 plus thirty-six 00's)
-** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's) 
+** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's)
 * Range in base58check encoding for EC-multiplied keys without compression (prefix 6Pf):
 ** Minimum value: 6PfKzduKZXAFXWMtJ19Vg9cSvbFg4va6U8p2VWzSjtHQCCLk3JSBpUvfpf (based on 01 43 00 plus thirty-six 00's)
 ** Maximum value: 6PfYiPy6Z7BQAwEHLxxrCEHrH9kasVQ95ST1NnuEnnYAJHGsgpNPQ9dTHc (based on 01 43 00 plus thirty-six FF's)
@@ -272,17 +272,17 @@ Test 2:
 
 Test 1:
 *Passphrase: MOLON LABE
-*Passphrase code: passphraseaB8feaLQDENqCgr4gKZpmf4VoaT6qdjJNJiv7fsKvjqavcJxvuR1hy25aTu5sX 
+*Passphrase code: passphraseaB8feaLQDENqCgr4gKZpmf4VoaT6qdjJNJiv7fsKvjqavcJxvuR1hy25aTu5sX
 *Encrypted key: 6PgNBNNzDkKdhkT6uJntUXwwzQV8Rr2tZcbkDcuC9DZRsS6AtHts4Ypo1j
 *Bitcoin address: 1Jscj8ALrYu2y9TD8NrpvDBugPedmbj4Yh
 *Unencrypted private key (WIF): 5JLdxTtcTHcfYcmJsNVy1v2PMDx432JPoYcBTVVRHpPaxUrdtf8
 *Unencrypted private key (hex): 44EA95AFBF138356A05EA32110DFD627232D0F2991AD221187BE356F19FA8190
 *Confirmation code: cfrm38V8aXBn7JWA1ESmFMUn6erxeBGZGAxJPY4e36S9QWkzZKtaVqLNMgnifETYw7BPwWC9aPD
 *Lot/Sequence: 263183/1
 
-Test 2: 
+Test 2:
 *Passphrase (all letters are Greek - test UTF-8 compatibility with this): ΜΟΛΩΝ ΛΑΒΕ
-*Passphrase code: passphrased3z9rQJHSyBkNBwTRPkUGNVEVrUAcfAXDyRU1V28ie6hNFbqDwbFBvsTK7yWVK 
+*Passphrase code: passphrased3z9rQJHSyBkNBwTRPkUGNVEVrUAcfAXDyRU1V28ie6hNFbqDwbFBvsTK7yWVK
 *Encrypted private key: 6PgGWtx25kUg8QWvwuJAgorN6k9FbE25rv5dMRwu5SKMnfpfVe5mar2ngH
 *Bitcoin address: 1Lurmih3KruL4xDB5FmHof38yawNtP9oGf
 *Unencrypted private key (WIF): 5KMKKuUmAkiNbA3DazMQiLfDq47qs8MAEThm4yL8R2PhV1ov33D

bip-0042.mediawiki

@@ -42,7 +42,7 @@ Note that several other programming languages do not exhibit this behaviour, mak
 
 ===Floating-point approximation===
 
-An obvious solution would be to reimplement the shape of the subsidy curve using floating-point approximations, such as simulated annealing or quantitative easing, which have already proven their worth in consensus systems. Unfortunately, since the financial crisis everyone considers numbers with decimal points in them fishy, and integers are not well supported by Javascript. 
+An obvious solution would be to reimplement the shape of the subsidy curve using floating-point approximations, such as simulated annealing or quantitative easing, which have already proven their worth in consensus systems. Unfortunately, since the financial crisis everyone considers numbers with decimal points in them fishy, and integers are not well supported by Javascript.
 
 ===Truncation===
 

bip-0052.mediawiki

@@ -25,7 +25,7 @@ Bitcoin network cannot profitably mine Bitcoin even if they have the capital to
 invest in mining hardware. From a practical perspective, Bitcoin adoption by
 companies like Tesla (which recently rescinded its acceptance of Bitcoin as
 payment) has been hampered by its massive energy consumption and perceived
-environmental impact. 
+environmental impact.
 
 <img src="bip-0052/btc_energy-small.png"></img>
 
@@ -137,7 +137,7 @@ x1 <- keccak(input)
 x2 <- reshape(x1, 64)
 
 // Perform a matrix-vector multiplication.
-// The result is 64-vector of 14-bit unsigned. 
+// The result is 64-vector of 14-bit unsigned.
 x3 <- vector_matrix_mult(x2, M)
 
 // Truncate all values to 4 most significant bits.

bip-0064.mediawiki

@@ -86,7 +86,7 @@ If the requesting client is looking up outputs for a signed transaction that the
 client can partly verify the returned output by running the input scripts with it. Currently this
 verifies only that the script is correct. A future version of the Bitcoin protocol is likely to also
 allow the value to be checked in this way. It does not show that the output is really unspent or was
-ever actually created in the block chain however. Additionally, the form of the provided scriptPubKey 
+ever actually created in the block chain however. Additionally, the form of the provided scriptPubKey
 should be checked before execution to ensure the remote peer doesn't just set the script to OP_TRUE.
 
 If the requesting client has a mapping of chain heights to block hashes in the best chain e.g.

bip-0065.mediawiki

@@ -205,19 +205,19 @@ transaction output ''can'' be spent.
 Refer to the reference implementation, reproduced below, for the precise
 semantics and detailed rationale for those semantics.
 
-    
+
     case OP_NOP2:
     {
         // CHECKLOCKTIMEVERIFY
         //
         // (nLockTime -- nLockTime )
-    
+
         if (!(flags & SCRIPT_VERIFY_CHECKLOCKTIMEVERIFY))
             break; // not enabled; treat as a NOP
-    
+
         if (stack.size() < 1)
             return false;
-    
+
         // Note that elsewhere numeric opcodes are limited to
         // operands in the range -2**31+1 to 2**31-1, however it is
         // legal for opcodes to produce results exceeding that
@@ -233,13 +233,13 @@ semantics and detailed rationale for those semantics.
         // to 5-byte bignums, which are good until 2**32-1, the
         // same limit as the nLockTime field itself.
         const CScriptNum nLockTime(stacktop(-1), 5);
-    
+
         // In the rare event that the argument may be < 0 due to
         // some arithmetic being done first, you can always use
         // 0 MAX CHECKLOCKTIMEVERIFY.
         if (nLockTime < 0)
             return false;
-    
+
         // There are two types of nLockTime: lock-by-blockheight
         // and lock-by-blocktime, distinguished by whether
         // nLockTime < LOCKTIME_THRESHOLD.
@@ -252,12 +252,12 @@ semantics and detailed rationale for those semantics.
               (txTo.nLockTime >= LOCKTIME_THRESHOLD && nLockTime >= LOCKTIME_THRESHOLD)
              ))
             return false;
-    
+
         // Now that we know we're comparing apples-to-apples, the
         // comparison is a simple numeric one.
         if (nLockTime > (int64_t)txTo.nLockTime)
             return false;
-    
+
         // Finally the nLockTime feature can be disabled and thus
         // CHECKLOCKTIMEVERIFY bypassed if every txin has been
         // finalized by setting nSequence to maxint. The
@@ -270,9 +270,9 @@ semantics and detailed rationale for those semantics.
         // required to prove correct CHECKLOCKTIMEVERIFY execution.
         if (txTo.vin[nIn].IsFinal())
             return false;
-    
+
         break;
-    
+
     }
 
 https://github.com/petertodd/bitcoin/commit/ab0f54f38e08ee1e50ff72f801680ee84d0f1bf4

bip-0066.mediawiki

@@ -75,7 +75,7 @@ bool static IsValidSignatureEncoding(const std::vector<unsigned char> &sig) {
     // Verify that the length of the signature matches the sum of the length
     // of the elements.
     if ((size_t)(lenR + lenS + 7) != sig.size()) return false;
- 
+
     // Check whether the R element is an integer.
     if (sig[2] != 0x02) return false;
 
@@ -140,7 +140,7 @@ An implementation for the reference client is available at https://github.com/bi
 
 ==Acknowledgements==
 
-This document is extracted from the previous BIP62 proposal, which had input from various people, in particular Greg Maxwell and Peter Todd, who gave feedback about this document as well. 
+This document is extracted from the previous BIP62 proposal, which had input from various people, in particular Greg Maxwell and Peter Todd, who gave feedback about this document as well.
 
 ==Disclosures==
 

bip-0067.mediawiki

@@ -19,39 +19,39 @@ This BIP describes a method to deterministically generate multi-signature pay-to
 
 ==Motivation==
 
-Pay-to-script-hash (BIP-0011<ref>[https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki BIP-0011]</ref>) is a transaction type that allows funding of arbitrary scripts, where the recipient carries the cost of fee's associated with using longer, more complex scripts. 
+Pay-to-script-hash (BIP-0011<ref>[https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki BIP-0011]</ref>) is a transaction type that allows funding of arbitrary scripts, where the recipient carries the cost of fee's associated with using longer, more complex scripts.
 
 Multi-signature pay-to-script-hash transactions are defined in BIP-0016<ref>[https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki BIP-0016]</ref>. The redeem script does not require a particular ordering or encoding for public keys.  This means that for a given set of keys and number of required signatures, there are as many as 2(n!) possible standard redeem scripts, each with its separate P2SH address.  Adhering to an ordering and key encoding would ensure that a multi-signature “account” (set of public keys and required signature count) has a canonical P2SH address.
 
 By adopting a sorting and encoding standard, compliant wallets will always produce the same P2SH address for the same given set of keys and required signature count, making it easier to recognize transactions involving that multi-signature account.  This is particularly attractive for multisignature hierarchical-deterministic wallets, as less state is required to setup multi-signature accounts:  only the number of required signatures and master public keys of participants need to be shared, and all wallets will generate the same addresses.
 
 While most web wallets do not presently facilitate the setup of multisignature accounts with users of a different service, conventions which ensure cross-compatibility should make it easier to achieve this.
 
-Many wallet as a service providers use a 2of3 multi-signature schema where the user stores 1 of the keys (offline) as backup while using the other key for daily use and letting the service cosign his transactions.  
+Many wallet as a service providers use a 2of3 multi-signature schema where the user stores 1 of the keys (offline) as backup while using the other key for daily use and letting the service cosign his transactions.
 This standard will help in enabling a party other than the service provider to recover the wallet without any help from the service provider.
 
 ==Specification==
 
 For a set of public keys, ensure that they have been received in compressed form:
-    
+
     022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
-    03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9 
+    03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
     021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
- 
-Sort them lexicographically according to their binary representation: 
-    
+
+Sort them lexicographically according to their binary representation:
+
     021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
     022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
     03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
 
-..before using the resulting list of keys in a standard multisig redeem script:  
-    
+..before using the resulting list of keys in a standard multisig redeem script:
+
     OP_2 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9 OP_3 OP_CHECKMULTISIG
 
 Hash the redeem script according to BIP-0016 to get the P2SH address.
-    
+
     3Q4sF6tv9wsdqu2NtARzNCpQgwifm2rAba
-    
+
 ==Compatibility==
 * Uncompressed keys are incompatible with this specification. A compatible implementation should not automatically compress keys.  Receiving an uncompressed key from a multisig participant should be interpreted as a sign that the user has an incompatible implementation.
 * P2SH addresses do not reveal information about the script that is receiving the funds. For this reason it is not technically possible to enforce this BIP as a rule on the network.  Also, it would cause a hard fork.
@@ -75,11 +75,11 @@ Vector 1
 ** 39bgKC7RFbpoCRbtD5KEdkYKtNyhpsNa3Z
 
 Vector 2 (Already sorted, no action required)
-* List: 
+* List:
 ** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0
 ** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77
 ** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404
-* Sorted: 
+* Sorted:
 ** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0
 ** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77
 ** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404
@@ -89,12 +89,12 @@ Vector 2 (Already sorted, no action required)
 ** 3CKHTjBKxCARLzwABMu9yD85kvtm7WnMfH
 
 Vector 3:
-* List:    
+* List:
 ** 030000000000000000000000000000000000004141414141414141414141414141
 ** 020000000000000000000000000000000000004141414141414141414141414141
 ** 020000000000000000000000000000000000004141414141414141414141414140
 ** 030000000000000000000000000000000000004141414141414141414141414140
-* Sorted: 
+* Sorted:
 ** 020000000000000000000000000000000000004141414141414141414141414140
 ** 020000000000000000000000000000000000004141414141414141414141414141
 ** 030000000000000000000000000000000000004141414141414141414141414140
@@ -105,11 +105,11 @@ Vector 3:
 ** 32V85igBri9zcfBRVupVvwK18NFtS37FuD
 
 Vector 4: (from bitcore)
-* List: 
+* List:
 ** 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
-** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9 
+** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
 ** 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
-* Sorted: 
+* Sorted:
 ** 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
 ** 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
 ** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
@@ -119,13 +119,13 @@ Vector 4: (from bitcore)
 ** 3Q4sF6tv9wsdqu2NtARzNCpQgwifm2rAba
 
 ==Acknowledgements==
-The authors wish to thank BtcDrak and Luke-Jr for their involvement & contributions in the early discussions of this BIP. 
+The authors wish to thank BtcDrak and Luke-Jr for their involvement & contributions in the early discussions of this BIP.
 
-==Usage & Implementations== 
-* [[https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki#address-generation-procedure|BIP-0045]] - Structure for Deterministic P2SH Multisignature Wallets 
-* [[https://github.com/bitpay/bitcore/blob/50a868cb8cdf2be04bb1c5bf4bcc064cc06f5888/lib/script/script.js#L541|Bitcore]] 
+==Usage & Implementations==
+* [[https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki#address-generation-procedure|BIP-0045]] - Structure for Deterministic P2SH Multisignature Wallets
+* [[https://github.com/bitpay/bitcore/blob/50a868cb8cdf2be04bb1c5bf4bcc064cc06f5888/lib/script/script.js#L541|Bitcore]]
 * [[https://github.com/haskoin/haskoin-core/blob/b41b1deb0989334a7ead6fc993fb8b02f0c00810/haskoin-core/Network/Haskoin/Script/Parser.hs#L112-L122|Haskoin]] - Bitcoin implementation in Haskell
-* [[https://github.com/etotheipi/BitcoinArmory/blob/268db0f3fa20c989057bd43343a43b2edbe89aeb/armoryengine/ArmoryUtils.py#L1441|Armory]] 
+* [[https://github.com/etotheipi/BitcoinArmory/blob/268db0f3fa20c989057bd43343a43b2edbe89aeb/armoryengine/ArmoryUtils.py#L1441|Armory]]
 * [[https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/script/ScriptBuilder.java#L331|BitcoinJ]]
 
 == References ==

bip-0068.mediawiki

@@ -33,7 +33,7 @@ If bit (1 << 31) of the sequence number is set, then no consensus meaning is app
 
 If bit (1 << 31) of the sequence number is not set, then the sequence number is interpreted as an encoded relative lock-time.
 
-The sequence number encoding is interpreted as follows: 
+The sequence number encoding is interpreted as follows:
 
 Bit (1 << 22) determines if the relative lock-time is time-based or block based: If the bit is set, the relative lock-time specifies a timespan in units of 512 seconds granularity. The timespan starts from the median-time-past of the output’s previous block, and ends at the MTP of the previous block. If the bit is not set, the relative lock-time specifies a number of blocks.
 
@@ -65,7 +65,7 @@ enum {
     /* Interpret sequence numbers as relative lock-time constraints. */
     LOCKTIME_VERIFY_SEQUENCE = (1 << 0),
 };
-    
+
 /* Setting nSequence to this value for every input in a transaction
  * disables nLockTime. */
 static const uint32_t SEQUENCE_FINAL = 0xffffffff;
@@ -245,7 +245,7 @@ The most efficient way to calculate sequence number from relative lock-time is w
     // 0 <= nHeight < 65,535 blocks (1.25 years)
     nSequence = nHeight;
     nHeight = nSequence & 0x0000ffff;
-    
+
     // 0 <= nTime < 33,554,431 seconds (1.06 years)
     nSequence = (1 << 22) | (nTime >> 9);
     nTime = (nSequence & 0x0000ffff) << 9;