From befa252b515d4104157bc57d3797050da51627fc Mon Sep 17 00:00:00 2001 From: wgyt Date: Mon, 14 Apr 2025 23:22:17 +0800 Subject: [PATCH] BIP3,37,39,42,52,62: fix typos (#1824) Co-authored-by: Mark "Murch" Erhardt --- bip-0003.md | 4 ++-- bip-0037.mediawiki | 2 +- bip-0039/bip-0039-wordlists.md | 2 +- bip-0042.mediawiki | 2 +- bip-0052.mediawiki | 2 +- bip-0062.mediawiki | 2 +- 6 files changed, 7 insertions(+), 7 deletions(-) diff --git a/bip-0003.md b/bip-0003.md index e81e3e2a..1624e50e 100644 --- a/bip-0003.md +++ b/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?** diff --git a/bip-0037.mediawiki b/bip-0037.mediawiki index d817bc01..ba207b6d 100644 --- a/bip-0037.mediawiki +++ b/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. diff --git a/bip-0039/bip-0039-wordlists.md b/bip-0039/bip-0039-wordlists.md index ebc93ddc..e83cf130 100644 --- a/bip-0039/bip-0039-wordlists.md +++ b/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. diff --git a/bip-0042.mediawiki b/bip-0042.mediawiki index c233e268..d9cde156 100644 --- a/bip-0042.mediawiki +++ b/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. diff --git a/bip-0052.mediawiki b/bip-0052.mediawiki index aa42ab38..ab86ca22 100644 --- a/bip-0052.mediawiki +++ b/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 diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki index 7dd2b5b6..418c2e45 100644 --- a/bip-0062.mediawiki +++ b/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.