BIP3,37,39,42,52,62: fix typos (#1824)

Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>

bip-0003.md

@@ -96,7 +96,7 @@ following list and address each as appropriate.
 * Rationale — The rationale fleshes out the specification by describing what inspired the design and why particular
   design decisions were made. It should describe related work and alternate designs that were considered. The rationale
   should record relevant objections or important concerns that were raised and addressed as this proposal was developed.
-* Backward Compatibility — Any BIP that introduces incompatibilities must include a section describing these incompatibities and their severity as well as provide instructions on how
+* Backward Compatibility — Any BIP that introduces incompatibilities must include a section describing these incompatibilities and their severity as well as provide instructions on how
   implementers and users should deal with these incompatibilities.
 * Reference Implementation — Where applicable, a reference implementation, test vectors, and documentation must be
   finished before the BIP can be given the status "Complete". Test vectors must be provided in the BIP or
@@ -686,7 +686,7 @@ feedback, and helpful comments.
     raised that making announcements to the Bitcoin Developer Mailing List would introduce unnecessary noise, our
     rationale is that 1) moving Complete and Deployed BIPs to the Closed status will be a rare occurrence, 2) status
     updates will usually not generate a lot of discussion, 3) while the mailing list should preferably only used for
-    getting review for new BIPs, it is the only channel available to us that can be consider a public announcement to
+    getting review for new BIPs, it is the only channel available to us that can be considered a public announcement to
     the audience of the BIPs repository: even if the authors, implementers, or other parties interested in a BIP do not
     see the announcement themselves, they may be made aware by someone that does see it.
 [^superseded-by-proposed-replacement]: **Why is Superseded-By replaced with Proposed-Replacement?**  

bip-0037.mediawiki

@@ -159,7 +159,7 @@ A ''Merkle tree'' is a way of arranging a set of items as leaf nodes of tree in
 ** Check whether this node corresponds to a leaf node (transaction) that is to be included OR any parent thereof:
 *** If so, append a '1' bit to the flag bits
 *** Otherwise, append a '0' bit.
-** Check whether this node is a internal node (non-leaf) AND is the parent of an included leaf node:
+** Check whether this node is an internal node (non-leaf) AND is the parent of an included leaf node:
 *** If so:
 **** Descend into its left child node, and process the subtree beneath it entirely (depth-first).
 **** If this node has a right child node too, descend into it as well.

bip-0039/bip-0039-wordlists.md

@@ -50,7 +50,7 @@ Credits: @Kirvx @NicolasDorier @ecdsa @EricLarch
 4.  Only infinitive verbs, adjectives and nouns.
 5.  No pronouns, no adverbs, no prepositions, no conjunctions, no interjections (unless a noun/adjective is also popular than its interjection like "mince;chouette").
 6.  No numeral adjectives.
-7.  No words in the plural (except invariable words like "univers", or same spelling than singular like "heureux").
+7.  No words in the plural (except invariable words like "univers", or same spelling as singular like "heureux").
 8.  No female adjectives (except words with same spelling for male and female adjectives like "magique").
 9.  No words with several senses AND different spelling in speaking like "verre-vert", unless a word has a meaning much more popular than another like "perle" and "pairle".
 10. No very similar words with only 1 letter of difference.

bip-0042.mediawiki

@@ -13,7 +13,7 @@
 
 ==Abstract==
 
-Although it is widely believed that Satoshi was an inflation-hating goldbug he never said this, and in fact programmed Bitcoin's money supply to grow indefinitely, forever. He modeled the monetary supply as 4 gold mines being discovered per mibillenium (1024 years), with equal intervals between them, each one being depleted over the course of 140 years.
+Although it is widely believed that Satoshi was an inflation-hating goldbug he never said this, and in fact programmed Bitcoin's money supply to grow indefinitely, forever. He modeled the monetary supply as 4 gold mines being discovered per mibillennium (1024 years), with equal intervals between them, each one being depleted over the course of 140 years.
 
 This poses obvious problems, however. Prominent among them is the discussion on what to call 1 billion bitcoin, which symbol color to use for it, and when wallet clients should switch to it by default.
 

bip-0052.mediawiki

@@ -118,7 +118,7 @@ The HeavyHash is performed in three stages:
 
 # Keccak hash
 # Matrix-vector multiplication
-# Keccak of the result xorred with the hashed input
+# Keccak of the result xored with the hashed input
 
 Note that the most efficient matrix-vector multiplication is performed on a
 photonic miner. However, this linear algebra operation can be performed on any

bip-0062.mediawiki

@@ -34,7 +34,7 @@ Several sources of malleability are known:
 
 # '''Non-DER encoded ECDSA signatures''' Right now, the Bitcoin reference client uses OpenSSL to validate signatures. As OpenSSL accepts more than serializations that strictly adhere to the DER standard, this is a source of malleability. Since v0.8.0, non-DER signatures are no longer relayed already.
 # '''Non-push operations in scriptSig''' Any sequence of script operations in scriptSig that results in the intended data pushes, but is not just a push of that data, results in an alternative transaction with the same validity.
-# '''Push operations in scriptSig of non-standard size type''' The Bitcoin scripting language has several push operators (OP_0, single-byte pushes, data pushes of up to 75 bytes, OP_PUSHDATA1, OP_PUSHDATA2, OP_PUSHDATA4). As the later ones have the same result as the former ones, they result in additional possibilities.
+# '''Push operations in scriptSig of non-standard size type''' The Bitcoin scripting language has several push operators (OP_0, single-byte pushes, data pushes of up to 75 bytes, OP_PUSHDATA1, OP_PUSHDATA2, OP_PUSHDATA4). As the latter ones have the same result as the former ones, they result in additional possibilities.
 # '''Zero-padded number pushes''' In cases where scriptPubKey opcodes use inputs that are interpreted as numbers, they can be zero padded.
 # '''Inherent ECDSA signature malleability''' ECDSA signatures themselves are already malleable: taking the negative of the number S inside (modulo the curve order) does not invalidate it.
 # '''Superfluous scriptSig operations''' Adding extra data pushes at the start of scripts, which are not consumed by the corresponding scriptPubKey, is also a source of malleability.