Fixing spelling in multiple BIPs

meshcollider · luke-jr · commit 6295c1a095a1 · 2017-09-16T03:12:13.000Z
diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
@@ -113,7 +113,7 @@ referred to as MTP in the diagram above, and is treated as a monotonic clock def
 After a period in the STARTED state, if we're past the timeout, we switch to FAILED. If not, we tally the bits set,
 and transition to LOCKED_IN if a sufficient number of blocks in the past period set the deployment bit in their
 version numbers. The threshold is ≥1916 blocks (95% of 2016), or ≥1512 for testnet (75% of 2016).
-The transition to FAILED takes precendence, as otherwise an ambiguity can arise.
+The transition to FAILED takes precedence, as otherwise an ambiguity can arise.
 There could be two non-overlapping deployments on the same bit, where the first one transitions to LOCKED_IN while the
 other one simultaneously transitions to STARTED, which would mean both would demand setting the bit.
 
diff --git a/bip-0019.mediawiki b/bip-0019.mediawiki
@@ -46,7 +46,7 @@ But only for n less than or equal to 3.
 These transactions are redeemed using a standard scriptSig:
     ...signatures...
 
-The current Satoshi bitcoin client does not relay or mine transactions with scriptSigs larger than 200 bytes; to accomodate 3-signature transactions, this will be increased to 500 bytes.
+The current Satoshi bitcoin client does not relay or mine transactions with scriptSigs larger than 200 bytes; to accommodate 3-signature transactions, this will be increased to 500 bytes.
 
 ===Templates===
 scriptPubKey:
diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki
@@ -156,7 +156,7 @@ In case I<sub>L</sub> is 0 or ≥n, the master key is invalid.
 
 ==Specification: Wallet structure==
 
-The previous sections specified key trees and their nodes. The next step is imposing a wallet structure on this tree. The layout defined in this section is a default only, though clients are encouraged to mimick it for compatibility, even if not all features are supported.
+The previous sections specified key trees and their nodes. The next step is imposing a wallet structure on this tree. The layout defined in this section is a default only, though clients are encouraged to mimic it for compatibility, even if not all features are supported.
 
 ===The default wallet layout===
 
@@ -292,7 +292,7 @@ hdkeychain (https://github.com/conformal/btcutil/tree/master/hdkeychain) provide
 
 Two JavaScript implementations exist: available at https://github.com/sarchar/brainwallet.github.com/tree/bip32 and https://github.com/bitpay/bitcore
 
-A PHP implemetation is available at https://github.com/Bit-Wasp/bitcoin-lib-php
+A PHP implementation is available at https://github.com/Bit-Wasp/bitcoin-lib-php
 
 A C# implementation is available at https://github.com/NicolasDorier/NBitcoin (ExtKey, ExtPubKey)
 
diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki
@@ -25,7 +25,7 @@ BIP-0032 or similar methods.
 ==Motivation==
 
 A mnemonic code or sentence is superior for human interaction compared to the
-handling of raw binary or hexidecimal representations of a wallet seed. The
+handling of raw binary or hexadecimal representations of a wallet seed. The
 sentence could be written on paper or spoken over the telephone.
 
 This guide is meant to be a way to transport computer-generated randomness with
diff --git a/bip-0045.mediawiki b/bip-0045.mediawiki
@@ -192,7 +192,7 @@ an external chain by generating a new address.
 
 ===Rationale===
 
-This stucture provides a general way of doing HDPM wallets between m-of-n
+This structure provides a general way of doing HDPM wallets between m-of-n
 parties. Here are some explanations about the design decisions made.
 
 The reason for using separate branches for each cosigner is we don't want
diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki
@@ -312,7 +312,7 @@ A recipient specifies their preference for alternate notification by setting the
 
 ===Bitmessage Notification===
 
-A recipient prefers to receive notifications via Bitmessage indiates this preference by:
+A recipient which prefers to receive notifications via Bitmessage indicates this preference by:
 
 * Setting bit 0 of the features byte to 1
 * Setting byte 67 of the serialized payment code to the desired Bitmessage address version
diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki
@@ -94,7 +94,7 @@ There exist a number of protocols where a transaction output is created that
 requires the co-operation of both parties to spend the output. To ensure the
 failure of one party does not result in the funds becoming lost, refund
 transactions are setup in advance using nLockTime. These refund transactions
-need to be created interactively, and additionaly, are currently vulnerable to
+need to be created interactively, and additionally, are currently vulnerable to
 transaction malleability. CHECKLOCKTIMEVERIFY can be used in these protocols,
 replacing the interactive setup with a non-interactive setup, and additionally,
 making transaction malleability a non-issue.
diff --git a/bip-0075.mediawiki b/bip-0075.mediawiki
@@ -174,7 +174,7 @@ message ProtocolMessage {
 ===Versioning===
 This BIP introduces version 1 of this protocol. All messages sent using these base requirements MUST use a value of 1 for the version number. Any future BIPs that modify this protocol (encryption schemes, etc) MUST each increment the version number by 1.
 
-When initiating communication, the version field of the first message SHOULD be set to the highest verison number the sender understands. All clients MUST be able to understand all version numbers less than the highest number they support. If a client receives a message with a version number higher than they understand, they MUST send the message back to the sender with a status code of 101 ("version too high") and the version field set to the highest version number the recipient understands. The sender must then resend the original message using the same version number returned by the recipient or abort.
+When initiating communication, the version field of the first message SHOULD be set to the highest version number the sender understands. All clients MUST be able to understand all version numbers less than the highest number they support. If a client receives a message with a version number higher than they understand, they MUST send the message back to the sender with a status code of 101 ("version too high") and the version field set to the highest version number the recipient understands. The sender must then resend the original message using the same version number returned by the recipient or abort.
 
 ===EncryptedProtocolMessage===
 The '''EncryptedProtocolMessage''' message is an encapsualting wrapper for any Payment Protocol message. It allows two-way, authenticated and encrypted communication of Payment Protocol messages in order to keep their contents secret. The message also includes a status code and status message that is used for error communication such that the protocol does not rely on transport-layer error handling.
diff --git a/bip-0080.mediawiki b/bip-0080.mediawiki
@@ -59,7 +59,7 @@ Hardened derivation is used at this level.
 
 Public/private keypairs are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation.
 
-Public keys obtained at this level of the heirarchy are used to construct multisig deposit scripts, using a schema that is shared between the members as an out-of-band contract.
+Public keys obtained at this level of the hierarchy are used to construct multisig deposit scripts, using a schema that is shared between the members as an out-of-band contract.
 
 Public derivation is used at this level.
 
diff --git a/bip-0081.mediawiki b/bip-0081.mediawiki
@@ -55,7 +55,7 @@ Public derivation is used at these levels, even when the index exceeds 2^31.
 
 Public/private keypairs are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation.
 
-Public keys obtained at this level of the heirarchy are used to construct multisig deposit scripts, using a schema that is shared between the members as an out-of-band contract.
+Public keys obtained at this level of the hierarchy are used to construct multisig deposit scripts, using a schema that is shared between the members as an out-of-band contract.
 
 Public derivation is used at this level.
 
diff --git a/bip-0099.mediawiki b/bip-0099.mediawiki
@@ -144,7 +144,7 @@ unnecessary.
 Fundamental disagreements and controversies are part of social
 systems, like the one defined as the human participants in the Bitcoin
 network. Without judging the motivation of the rule discrepancies or
-what rules were in place first, we're definining schism[1] hardforks as
+what rules were in place first, we're defining schism[1] hardforks as
 those in which - for whatever reason - users are consiously going to validate 2
 different sets of consensus rules. Since they will validate different
 rulesets, they will end up following 2 different chains for at least
diff --git a/bip-0103.mediawiki b/bip-0103.mediawiki
@@ -73,7 +73,7 @@ Using a time-based check is very simple to implement, needs little context, is e
 
 ==Compatibility==
 
-This is a hard forking change, thus breaks compatbility with old fully-validating node. It should not be deployed without widespread consensus.
+This is a hard forking change, thus breaks compatibility with old fully-validating node. It should not be deployed without widespread consensus.
 
 ==Acknowledgements==
 
diff --git a/bip-0106.mediawiki b/bip-0106.mediawiki
@@ -52,7 +52,7 @@ https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false&
 
 ==Rationale==
 
-These two proposals have been derived after discussion on [https://bitcointalk.org/index.php?topic=1154536.0 BitcoinTalk] and [http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010285.html bitcoin-dev mailing list]. The original idea and its evolution in the light of various arguements can be found [http://upalc.com/maxblocksize.php here].
+These two proposals have been derived after discussion on [https://bitcointalk.org/index.php?topic=1154536.0 BitcoinTalk] and [http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010285.html bitcoin-dev mailing list]. The original idea and its evolution in the light of various arguments can be found [http://upalc.com/maxblocksize.php here].
 
 ===Proposal 1 : Depending only on previous block size calculation===
 
diff --git a/bip-0140.mediawiki b/bip-0140.mediawiki
@@ -83,7 +83,7 @@ There are a number of advantages to using normalized transaction IDs:
 Scalable Off-Chain Instant Payments]]</ref> in which several parties sign a transaction. Without normalized transaction IDs it is trivial for one party to re-sign a transaction, hence changing the transaction hash and invalidating any transaction built on top of its outputs. Normalized transaction IDs force the ID not to change, even if a party replaces its signature.
 * Many higher level protocols build structures of transactions on top of multisig outputs that are not completely signed. This is currently not possible without one party holding a fully signed transaction and then calculating the ID. It is desirable to be able to build successive transactions without one party collecting all signatures, and thus possibly lock in funds unilaterally. Normalized transaction IDs allow the use of transaction templates, i.e., completely unsigned transactions upon which further transactions can be built, and only once every party is assured the structure matches its expectations it signs the template, thus validating the template.
 
-The only occurence in which transactions can still be modified unilaterally is in the case <code>SIGHASH_NONE</code>, <code>SIGHASH_SINGLE</code> or <code>SIGHASH_ANYONECANPAY</code> is used. This however is not problematic since in these cases the creator of the transaction explicitly allows modification.
+The only occurrence in which transactions can still be modified unilaterally is in the case <code>SIGHASH_NONE</code>, <code>SIGHASH_SINGLE</code> or <code>SIGHASH_ANYONECANPAY</code> is used. This however is not problematic since in these cases the creator of the transaction explicitly allows modification.
 
 In case of a transaction becoming invalid due to one of the inputs being malleated it is necessary to modify the spending transaction to reference the modified transaction ID. However, the signatures, which only use the normalized IDs, remain valid as long as the semantics of the funding transaction remain unchanged. An observer in the network may fix the transaction and reinject a corrected version.
 
diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki
@@ -67,7 +67,7 @@ The item 6 is a 8-byte value of the amount of bitcoin spent in this input.
 <code>hashOutputs</code>:
 *If the sighash type is neither <code>SINGLE</code> nor <code>NONE</code>, <code>hashOutputs</code> is the double SHA256 of the serialization of all output amount (8-byte little endian) with <code>scriptPubKey</code> (serialized as scripts inside CTxOuts);
 *If sighash type is <code>SINGLE</code> and the input index is smaller than the number of outputs, <code>hashOutputs</code> is the double SHA256 of the output amount with <code>scriptPubKey</code> of the same index as the input;
-*Otherwise, <code>hashOutputs</code> is a <code>uint256</code> of <code>0x0000......0000</code>.<ref>In the original algorithm, a <code>uint256</code> of <code>0x0000......0001</code> is commited if the input index for a <code>SINGLE</code> signature is greater than or equal to the number of outputs. In this BIP a <code>0x0000......0000</code> is commited, without changing the semantics.</ref>
+*Otherwise, <code>hashOutputs</code> is a <code>uint256</code> of <code>0x0000......0000</code>.<ref>In the original algorithm, a <code>uint256</code> of <code>0x0000......0001</code> is committed if the input index for a <code>SINGLE</code> signature is greater than or equal to the number of outputs. In this BIP a <code>0x0000......0000</code> is commited, without changing the semantics.</ref>
 
 The <code>hashPrevouts</code>, <code>hashSequence</code>, and <code>hashOutputs</code> calculated in an earlier verification may be reused in other inputs of the same transaction, so that the time complexity of the whole hashing process reduces from O(n<sup>2</sup>) to O(n).
 
@@ -282,7 +282,7 @@ This example shows how <code>OP_CODESEPARATOR</code> and out-of-range <code>SIGH
   The second input comes from a native P2WSH witness program:
     scriptPubKey : 00205d1b56b63d714eebe542309525f484b7e9d6f686b3781b6f61ef925d66d6f6a0, value: 49
     witnessScript: 21026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac
-                   <026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae> CHECKSIGVERIFY CODESEPERATOR <0255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465> CHECKSIG
+                   <026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae> CHECKSIGVERIFY CODESEPARATOR <0255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465> CHECKSIG
   
   To sign it with a nHashType of 3 (SIGHASH_SINGLE):
   
@@ -338,12 +338,12 @@ This example shows how unexecuted <code>OP_CODESEPARATOR</code> is processed, an
   The first input comes from a native P2WSH witness program:
     scriptPubKey: 0020ba468eea561b26301e4cf69fa34bde4ad60c81e70f059f045ca9a79931004a4d value: 0.16777215
     witnessScript:0063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac
-                  0 IF CODESEPERATOR ENDIF <0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98> CHECKSIG
+                  0 IF CODESEPARATOR ENDIF <0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98> CHECKSIG
   
   The second input comes from a native P2WSH witness program:
     scriptPubKey: 0020d9bbfbe56af7c4b7f960a70d7ea107156913d9e5a26b0a71429df5e097ca6537 value: 0.16777215
     witnessScript:5163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac
-                  1 IF CODESEPERATOR ENDIF <0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98> CHECKSIG
+                  1 IF CODESEPARATOR ENDIF <0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98> CHECKSIG
   
   To sign it with a nHashType of 0x83 (SINGLE|ANYONECANPAY):
   
