Merge pull request bitcoin#1603 from cocoyeal/remove_duplicated_words

Remove duplicated words

Author: jonatack

bip-0047.mediawiki

@@ -17,7 +17,7 @@ RECENT CHANGES:
 
 ==Status==
 
-This BIP can be be considered final in terms of enabling compatibility with wallets that implement version 1 and version 2 reusable payment codes, however future developments of the reusable payment codes specification will not be distributed via the BIP process.
+This BIP can be considered final in terms of enabling compatibility with wallets that implement version 1 and version 2 reusable payment codes, however future developments of the reusable payment codes specification will not be distributed via the BIP process.
 
 The Open Bitcoin Privacy Project RFC repo should be consulted for specifications related to version 3 or higher payment codes: https://github.com/OpenBitcoinPrivacyProject/rfc
 
@@ -350,12 +350,12 @@ Version 2 payment codes behave identifically to version 1 payment codes, except
 
 ====Definitions====
 
-* Notification change output: the change output from a notification transaction which which resides in the sender's wallet, but can be automatically located by the intended recipient
+* Notification change output: the change output from a notification transaction which resides in the sender's wallet, but can be automatically located by the intended recipient
 * Payment code identifier: a 33 byte representation of a payment code constructed by prepending 0x02 to the SHA256 hash of the binary serialization of the payment code
 
 ====Notification Transaction====
 
-Note: this procedure is used if Bob uses a version 2 payment code (regardless of the the version of Alice's payment code). If Bob's payment code is not version 2, see the appropriate section in this specification.
+Note: this procedure is used if Bob uses a version 2 payment code (regardless of the version of Alice's payment code). If Bob's payment code is not version 2, see the appropriate section in this specification.
 
 # Construct a notification transaction as per the version 1 instructions, except do not create the output to Bob's notification address
 # Create a notification change address as follows:

bip-0093.mediawiki

@@ -354,7 +354,7 @@ Instead every different language has it own word list (or word lists) and each c
 We would need to encode the choice of word list in our share's meta-data, which takes up even more room, and is difficult to specify due to the ever-evolving choice of word lists.
 
 Alternatively we could standardize on the choice of the English word list, something that is nearly a de facto standard, and simply be incompatible with BIP-0039 wallets of other languages.
-Such a choice also risks users of BIP-0039 recovering their entropy from their language, encoding it in in Codex32 and then failing to recover their wallet because the English word lists has replaced their language's word list.
+Such a choice also risks users of BIP-0039 recovering their entropy from their language, encoding it in Codex32 and then failing to recover their wallet because the English word lists has replaced their language's word list.
 
 The main advantage of this alternative approach would be that wallets could give users an option switch between backing up their entropy as a BIP-0039 mnemonic and in Codex32 format, but again, only if their language choice happens to be the English word list.
 In practice, we do not expect users in switch back and forth between backup formats, and instead just generate a fresh master seed using Codex32.

bip-0115.mediawiki

@@ -98,7 +98,7 @@ What if ParamBlockHash has leading zeros? Should this be prevented?
 
 * If leading zeros are included, they should be compared to the actual block hash. (If they were truncated, fewer bytes would be compared.)
 * It is unlikely that the leading zeros will ever be necessary for sufficient precision, so the additional space is not a concern.
-* Since all block hashes are in principle shorter than than 29 bytes, ParamBlockHash may not be larger than 28 bytes.
+* Since all block hashes are in principle shorter than 29 bytes, ParamBlockHash may not be larger than 28 bytes.
 
 Why is it safe to allow checking blocks as recently as the immediate previous block?
 

bip-0116.mediawiki

@@ -59,7 +59,7 @@ This includes execution pathways or policy conditions which end up not being nee
 Not only is it inefficient to require this unnecessary information to be present on the blockchain, albeit in the witness, it also impacts privacy and fungibility as some unused script policies may be identifying.
 Using a Merkle hash tree to commit to the policy options, and then only forcing revelation of the policy used at redemption minimizes this information leakage.
 
-Using Merkle hash trees to commit to policy allows for considerably more complex contracts than would would otherwise be possible, due to various built-in script size and runtime limitations.
+Using Merkle hash trees to commit to policy allows for considerably more complex contracts than would otherwise be possible, due to various built-in script size and runtime limitations.
 With Merkle commitments to policy these size and runtime limitations constrain the complexity of any one policy that can be used rather than the sum of all possible policies.
 
 ==Rationale==

bip-0135.mediawiki

@@ -170,7 +170,7 @@ A given deployment SHALL remain in the DEFINED state until it either passes the
 starttime (and becomes STARTED) or the timeout time (and becomes FAILED).
 
 Once a deployment has STARTED, the signal for that deployment SHALL be tallied
-over the the past windowsize blocks whenever a new block is received on that
+over the past windowsize blocks whenever a new block is received on that
 chain.
 
 A transition from the STARTED state to the LOCKED_IN state SHALL only occur
@@ -183,7 +183,7 @@ when all of these are true:
 A similar height synchronization precondition SHALL exist for the transition from
 LOCKED_IN to ACTIVE.
 These synchronization conditions are expressed by the "mod(height, windowsize) = 0"
-clauses in the diagram, and have been been added so that backward compatibility
+clauses in the diagram, and have been added so that backward compatibility
 with BIP9's use of the 2016-block re-targeting periods can be configured for
 existing deployments (see above 'Optional full backward compatibility' section).
 
@@ -261,7 +261,7 @@ proposal, although a conventional fallow period of 3 months is RECOMMENDED.
 Due to the constraints set by BIP 34, BIP 66 and BIP 65, there are only
 0x7FFFFFFB possible nVersion values available. This limits to at most 30
 independent deployments.
-By restricting the top 3 bits to 001 we we are left with 29 out of those for
+By restricting the top 3 bits to 001 we are left with 29 out of those for
 the purposes of this proposal, and support two future upgrades for different
 mechanisms (top bits 010 and 011).
 

bip-0350.mediawiki

@@ -217,7 +217,7 @@ their invalidity.
 
 Checksums are used to detect errors introduced into data during transfer. A hash function-based checksum such as Base58Check detects any type of error uniformly, but not all classes of errors are equally likely to occur in practice. Bech32 prioritizes detection of substitution errors, but improving detection of one error class inevitably worsens detection of other error classes. During the design of Bech32, it was assumed that other simple error patterns beside substitutions would have a similar detection rate as in a hash function-based design, and detection would only be worse for complex, impractical errors. The discovered insertion weakness shows that this is not the case.
 
-For Bech32m, we aim to retain Bech32's guarantees for substitution errors, but make sure that other common errors don't perform worse than a hash function-based checksum would. To make sure the new standard is easy to implement, we restrict the design space to only amending the final constant that is xored in, as it was [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-December/017521.html observed] that that is sufficient to mitigate the 'q' insertion issue while retaining the intended substitution error detection. In what follows, we explain how the new constant ''0x2bc830a3'' was chosen.
+For Bech32m, we aim to retain Bech32's guarantees for substitution errors, but make sure that other common errors don't perform worse than a hash function-based checksum would. To make sure the new standard is easy to implement, we restrict the design space to only amending the final constant that is xored in, as it was [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-December/017521.html observed] that is sufficient to mitigate the 'q' insertion issue while retaining the intended substitution error detection. In what follows, we explain how the new constant ''0x2bc830a3'' was chosen.
 
 ===Error patterns & detection probability===
 

bip-0352.mediawiki

@@ -451,7 +451,7 @@ This distinction makes the problem for light clients more clear: light clients n
 
 Recall that a silent payment eligible transaction follows [[#scanning-silent-payment-eligible-transactions|certain conditions]] and should have at least one unspent taproot output. Full nodes (or any index server backed by a full node, such as electrum server) can build an index which collects all of the eligible public keys for a silent payments eligible transaction, sums them up, multiplies the sum by the ''input_hash'', and serves them to clients. This would be 33 bytes per silent payment eligible transaction.
 
-For a typical bitcoin block of ~3500 txs, lets assume every transaction is a silent payments eligible transaction. This means a client would need to request ''33 bytes * 3500'' of data per block (roughly 100 kB per block). If a client were to request data for every block, this would amount to ~450 MB per month, assuming 100% taproot usage and all outputs remain unspent for > 1 month. As of today, these numbers are closer to 2–10 kB per block (10–50 MB per month)<ref name="appendix_data">''' Data for Appendix A ''' These numbers are based on data from January 2023 until June 2023 (the last 6 months of data at time time of writing). See [https://github.com/josibake/bitcoin-data-analysis/blob/main/notebooks/silent-payments-light-client-data.ipynb Silent payments light client data] for the full analysis.</ref>.
+For a typical bitcoin block of ~3500 txs, lets assume every transaction is a silent payments eligible transaction. This means a client would need to request ''33 bytes * 3500'' of data per block (roughly 100 kB per block). If a client were to request data for every block, this would amount to ~450 MB per month, assuming 100% taproot usage and all outputs remain unspent for > 1 month. As of today, these numbers are closer to 2–10 kB per block (10–50 MB per month)<ref name="appendix_data">''' Data for Appendix A ''' These numbers are based on data from January 2023 until June 2023 (the last 6 months of data at the time of writing). See [https://github.com/josibake/bitcoin-data-analysis/blob/main/notebooks/silent-payments-light-client-data.ipynb Silent payments light client data] for the full analysis.</ref>.
 
 === Transaction cut-through ===
 

bip-0372.mediawiki

@@ -17,7 +17,7 @@
 ===Abstract===
 
 This document proposes additional fields for BIP 174 PSBTv0 and BIP 370 PSBTv2
-that allow for pay-to-contract key tweaking data data to be included in a PSBT
+that allow for pay-to-contract key tweaking data to be included in a PSBT
 of any version. These will represent an extra-transaction information required
 for the signer to produce valid signatures spending previous outputs.