diff --git a/bip-0015.mediawiki b/bip-0015.mediawiki index 52a698f2..1e9a9bc4 100644 --- a/bip-0015.mediawiki +++ b/bip-0015.mediawiki @@ -208,7 +208,7 @@ NameResolutionService::~NameResolutionService() void NameResolutionService::ExplodeHandle(const string& strHandle, string& strNickname, string& strDomain) { - // split address at @ furthrest to the right + // split address at @ furthest to the right size_t nPosAtsym = strHandle.rfind('@'); strNickname = strHandle.substr(0, nPosAtsym); strDomain = strHandle.substr(nPosAtsym + 1, strHandle.size()); diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki index dc1f5880..a15a15de 100644 --- a/bip-0047.mediawiki +++ b/bip-0047.mediawiki @@ -275,7 +275,7 @@ Normal operation of a payment code-enabled wallet can be performed by an SPV cli Recovering a wallet from a seed, however, does require access to a fully-indexed blockchain. -The required data may be obtained from copy of the blockchain under the control of the user, or via a publicly-queriable blockchain explorer. +The required data may be obtained from copy of the blockchain under the control of the user, or via a publicly-queryable blockchain explorer. When querying a public blockchain explorer, wallets SHOULD connect to the explorer through Tor (or equivalent) and SHOULD avoid grouping queries in a manner that associates ephemeral addresses with each other. diff --git a/bip-0049.mediawiki b/bip-0049.mediawiki index a13b437b..3e37a016 100644 --- a/bip-0049.mediawiki +++ b/bip-0049.mediawiki @@ -92,10 +92,10 @@ This BIP is not backwards compatible by design as described under [[#considerati // Account 0, first receiving private key = m/49'/1'/0'/0/0 account0recvPrivateKey = cULrpoZGXiuC19Uhvykx7NugygA3k86b3hmdCeyvHYQZSxojGyXJ account0recvPrivateKeyHex = 0xc9bdb49cfbaedca21c4b1f3a7803c34636b1d7dc55a717132443fc3f4c5867e8 - account0recvPublickKeyHex = 0x03a1af804ac108a8a51782198c2d034b28bf90c8803f5a53f76276fa69a4eae77f + account0recvPublicKeyHex = 0x03a1af804ac108a8a51782198c2d034b28bf90c8803f5a53f76276fa69a4eae77f // Address derivation - keyhash = HASH160(account0recvPublickKeyHex) = 0x38971f73930f6c141d977ac4fd4a727c854935b3 + keyhash = HASH160(account0recvPublicKeyHex) = 0x38971f73930f6c141d977ac4fd4a727c854935b3 scriptSig = <0 > = 0x001438971f73930f6c141d977ac4fd4a727c854935b3 addressBytes = HASH160(scriptSig) = 0x336caa13e08b96080a32b5d818d59b4ab3b36742 diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 7311d8a7..633210c6 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -364,7 +364,7 @@ This specification relies on BIP32 but is agnostic to how the BIP32 root key is ==Discussion== -The reason for running the derived key through HMAC-SHA512 and truncating the result as necessary is to prevent leakage of the parent tree should the derived key (''k'') be compromized. While the specification requires the use of hardended key derivation which would prevent this, we cannot enforce hardened derivation, so this method ensures the derived entropy is hardened. Also, from a semantic point of view, since the purpose is to derive entropy and not a private key, we are required to transform the child key. This is done out of an abundance of caution, in order to ward off unwanted side effects should ''k'' be used for a dual purpose, including as a nonce ''hash(k)'', where undesirable and unforeseen interactions could occur. +The reason for running the derived key through HMAC-SHA512 and truncating the result as necessary is to prevent leakage of the parent tree should the derived key (''k'') be compromised. While the specification requires the use of hardended key derivation which would prevent this, we cannot enforce hardened derivation, so this method ensures the derived entropy is hardened. Also, from a semantic point of view, since the purpose is to derive entropy and not a private key, we are required to transform the child key. This is done out of an abundance of caution, in order to ward off unwanted side effects should ''k'' be used for a dual purpose, including as a nonce ''hash(k)'', where undesirable and unforeseen interactions could occur. ==Acknowledgements== diff --git a/bip-0087.mediawiki b/bip-0087.mediawiki index 308e8521..920bd3cb 100644 --- a/bip-0087.mediawiki +++ b/bip-0087.mediawiki @@ -48,7 +48,7 @@ The second multisignature "standard" in use is m/48', which specifies: m / purpose' / coin_type' / account' / script_type' / change / address_index -Rather than following in BIP 44/49/84's path and having a separate BIP per script after P2SH (BIP45), vendors decided to insert script_type' into the derivation path (where P2SH-P2WSH=1, P2WSH=2, Future_Script=3, etc). As described previously, this is unnecessary, as the descriptor sets the script. While it attempts to reduce maintainence work by getting rid of new BIPs-per-script, it still requires maintaining an updated, redundant, script_type list. +Rather than following in BIP 44/49/84's path and having a separate BIP per script after P2SH (BIP45), vendors decided to insert script_type' into the derivation path (where P2SH-P2WSH=1, P2WSH=2, Future_Script=3, etc). As described previously, this is unnecessary, as the descriptor sets the script. While it attempts to reduce maintenance work by getting rid of new BIPs-per-script, it still requires maintaining an updated, redundant, script_type list. The structure proposed later in this paper solves these issues and is quite comprehensive. It allows for the handling of multiple accounts, external and internal chains per account, and millions of addresses per chain, in a multi-party, multisignature, hierarchical deterministic wallet regardless of the script type '''Why propose this structure only for multisignature wallets?''' Currently, single-sig wallets are able to restore funds using just the master private key data (in the format of BIP39 usually). Even if the user doesn't recall the derivation used, the wallet implementation can iterate through common schemes (BIP44/49/84). With this proposed hierarchy, the user would either have to now backup additional data (the descriptor), or the wallet would have to attempt all script types for every account level when restoring. Because of this, even though the descriptor language handles the signature type just like it does the script type, it is best to restrict this script-agnostic hierarchy to multisignature wallets only.. diff --git a/bip-0088.mediawiki b/bip-0088.mediawiki index 49be7dba..db21835e 100644 --- a/bip-0088.mediawiki +++ b/bip-0088.mediawiki @@ -41,7 +41,7 @@ addresses differently than the one they used before. The problem is common enough to warrant the creation of a dedicated website ([https://walletsrecovery.org/ walletsrecovery.org]) that tracks paths used by different wallets. -At the time of writing, this website has used their own format to succintly describe multiple +At the time of writing, this website has used their own format to succinctly describe multiple derivation paths. As far as author knows, it was the only publicitly used format to describe path templates before introduction of this BIP. The format was not specified anywhere beside the main page of the website. It used | to denote alternative derivation indexes @@ -52,7 +52,7 @@ an ad-hoc format only intended for illustration. In contrast to this ad-hoc form described in this BIP is intended for unambigouos parsing by software, and to be easily read by humans at the same time. Humans can visually detect the 'templated' parts of the path more easily than the use of | in the template could allow. Wider range of paths can be defined in a single template more -succintly and unambiguously. +succinctly and unambiguously. ===Intended use and advantages=== @@ -71,7 +71,7 @@ into using well-known paths, or convince other vendors to support their custom p scales poorly. A flexible approach proposed in this document is to define a standard notation for "BIP32 path templates" -that succintly describes the constraints to impose on the derivation path. +that succinctly describes the constraints to impose on the derivation path. Wide support for these path templates will increase interoperability and flexibility of solutions, and will allow vendors and individual developers to easily define their own custom restrictions. @@ -89,7 +89,7 @@ installation of malicious or incorrect profiles, though. ==Specification== -The format for the template was chosen to make it easy to read, convenient and visually unambigous. +The format for the template was chosen to make it easy to read, convenient and visually unambiguous. Template starts with optional prefix m/, and then one or more sections delimited by the slash character (/). diff --git a/bip-0098.mediawiki b/bip-0098.mediawiki index 8540d1ac..a296fdc8 100644 --- a/bip-0098.mediawiki +++ b/bip-0098.mediawiki @@ -241,16 +241,16 @@ Disallowing a node with two SKIP branches eliminates what would otherwise be a s The number of hashing operations required to verify a proof is one less than the number of hashes (SKIP and VERIFY combined), and is exactly equal to the number of inner nodes serialized as the beginning of the proof as N. -The variable-length integer encoding has the property that serialized integers, sorted lexigraphically, will also be sorted numerically. -Since the first serialized item is the number of inner nodes, sorting proofs lexigraphically has the effect of sorting the proofs by the amount of work required to verify. +The variable-length integer encoding has the property that serialized integers, sorted lexicographically, will also be sorted numerically. +Since the first serialized item is the number of inner nodes, sorting proofs lexicographically has the effect of sorting the proofs by the amount of work required to verify. The number of hashes required as input for verification of a proof is N+1 minus the number of SKIP hashes, and can be quickly calculated without parsing the tree structure. -The coding and packing rules for the serialized tree structure were also chosen to make lexigraphical comparison useful (or at least not meaningless). +The coding and packing rules for the serialized tree structure were also chosen to make lexicographical comparison useful (or at least not meaningless). If we consider a fully-expanded tree (no SKIP hashes, all VERIFY) to be encoding a list of elements in the order traversed depth-first from left-to-right, then we can extract proofs for subsets of the list by SKIP'ing the hashes of missing values and recursively pruning any resulting SKIP,SKIP nodes. -Lexigraphically comparing the resulting serialized tree structures is the same as lexigraphically comparing lists of indices from the original list verified by the derived proof. +Lexicographically comparing the resulting serialized tree structures is the same as lexicographically comparing lists of indices from the original list verified by the derived proof. Because the number of inner nodes and the number of SKIP hashes is extractible from the tree structure, both variable-length integers in the proof are redundant and could have been omitted. diff --git a/bip-0119.mediawiki b/bip-0119.mediawiki index d661f4c4..be1f70cb 100644 --- a/bip-0119.mediawiki +++ b/bip-0119.mediawiki @@ -193,7 +193,7 @@ Deployment could be done via BIP 9 VersionBits deployed through Speedy Trial. The Bitcoin Core reference implementation includes the below parameters, configured to match Speedy Trial, as that is the current activation mechanism implemented in Bitcoin Core. Should another method become favored by the wider -Bitcoin comminity, that might be used instead. +Bitcoin community, that might be used instead. The start time and bit in the implementation are currently set to bit 5 and NEVER_ACTIVE/NO_TIMEOUT, but this is subject to change while the BIP is a draft. @@ -314,7 +314,7 @@ We treat the number of inputs as a `uint32_t` because Bitcoin's consensus decodi to `MAX_SIZE=33554432` and that is larger than `uint16_t` and smaller than `uint32_t`. 32 bits is also friendly for manipulation using Bitcoin's current math opcodes, should `OP_CAT` be added. Note that the max inputs in a block is further restricted by the block size to around 25,000, which would fit -into a `uint16_t`, but that is an uneccessary abstraction leak. +into a `uint16_t`, but that is an unnecessary abstraction leak. =====Committing to the Sequences Hash===== @@ -362,7 +362,7 @@ scripts cannot be spent at the same index, which implies that they cannot be spe This makes it safer to design wallet vault contracts without half-spend vulnerabilities. Committing to the current index doesn't prevent one from expressing a CHECKTEMPLATEVERIFY which can -be spent at multiple indicies. In current script, the CHECKTEMPLATEVERIFY operation can be wrapped +be spent at multiple indices. In current script, the CHECKTEMPLATEVERIFY operation can be wrapped in an OP_IF for each index (or Tapscript branches in the future). If OP_CAT or OP_SHA256STREAM are added to Bitcoin, the index may simply be passed in by the witness before hashing. @@ -476,7 +476,7 @@ An example of a script that could experience an DoS issue without caching is: CTV CTV CTV... CTV -Such a script would cause the intepreter to compute hashes (supposing N CTV's) over O(N*T) data. +Such a script would cause the interpreter to compute hashes (supposing N CTV's) over O(N*T) data. If the scriptSigs non-nullity is not cached, then the O(T) transaction could be scanned over O(N) times as well (although cheaper than hashing, still a DoS). As such, CTV caches hashes and computations over all variable length fields in a transaction. @@ -616,7 +616,7 @@ sponsors might be considered. An opcode which verifies the exact amount that is being spent in the transaction, the amount paid as fees, or made available in a given output could -be used to make safer OP_CHECKTEMPLATEVERIFY addressses. For instance, if the +be used to make safer OP_CHECKTEMPLATEVERIFY addresses. For instance, if the OP_CHECKTEMPLATEVERIFY program P expects exactly S satoshis, sending S-1 satoshis would result in a frozen UTXO and sending S+n satoshis would result in n satoshis being paid to fee. A range check could restrict the program to only diff --git a/bip-0137.mediawiki b/bip-0137.mediawiki index 575440b1..ccba17fc 100644 --- a/bip-0137.mediawiki +++ b/bip-0137.mediawiki @@ -15,7 +15,7 @@ This document describes a signature format for signing messages with Bitcoin private keys. -The specification is intended to describe the standard for signatures of messages that can be signed and verfied between different clients that exist in the field today. Note: that a new signature format has been defined which has a number of advantages over this BIP, but to be backwards compatible with existing implementations this BIP will be useful. See BIP 322 [1] for full details on the new signature scheme. +The specification is intended to describe the standard for signatures of messages that can be signed and verified between different clients that exist in the field today. Note: that a new signature format has been defined which has a number of advantages over this BIP, but to be backwards compatible with existing implementations this BIP will be useful. See BIP 322 [1] for full details on the new signature scheme. One of the key problems in this area is that there are several different types of Bitcoin addresses and without introducing specific standards it is unclear which type of address format is being used. See [2]. This BIP will attempt to address these issues and define a clear and concise format for Bitcoin signatures. diff --git a/bip-0140.mediawiki b/bip-0140.mediawiki index 88131f49..c8f22f78 100644 --- a/bip-0140.mediawiki +++ b/bip-0140.mediawiki @@ -62,7 +62,7 @@ This is the standard ''m-of-n'' script defined in [https://github.com/bitcoin/bi The existing OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY have a bug[[https://bitcoin.org/en/developer-guide#multisig|Developer Documentation - Multisig]] that pops one argument too many from the stack. This bug is not reproduced in the implementation of OP_CHECKSIGEX, so the canonical solution of pushing a dummy value onto the stack is not necessary. The normalization is achieved by normalizing the transaction before computing the signaturehash, i.e., the hash that is signed. -The transaction must be normalized by replacing all transaction IDs in the inputs by their normalized variants and stripping the signature scripts. The normalized transction IDs are computed as described in the previous section. This normalization step is performed both when creating the signatures as well as when checking the signatures. +The transaction must be normalized by replacing all transaction IDs in the inputs by their normalized variants and stripping the signature scripts. The normalized transaction IDs are computed as described in the previous section. This normalization step is performed both when creating the signatures as well as when checking the signatures. === Tracking Normalized Transaction IDs === diff --git a/bip-0158/gentestvectors.go b/bip-0158/gentestvectors.go index e51b9842..2d11b144 100644 --- a/bip-0158/gentestvectors.go +++ b/bip-0158/gentestvectors.go @@ -37,7 +37,7 @@ var ( {49291, "Tx pays to empty output script"}, {180480, "Tx spends from empty output script"}, {926485, "Duplicate pushdata 913bcc2be49cb534c20474c4dee1e9c4c317e7eb"}, - {987876, "Coinbase tx has unparseable output script"}, + {987876, "Coinbase tx has unparsable output script"}, {1263442, "Includes witness data"}, {1414221, "Empty data"}, } diff --git a/bip-0327.mediawiki b/bip-0327.mediawiki index 4815f409..181926bf 100644 --- a/bip-0327.mediawiki +++ b/bip-0327.mediawiki @@ -554,7 +554,7 @@ influence whether ''sk1'' or ''sk2'' is provided to ''Sign This degree of freedom may allow the adversary to perform a generalized birthday attack and thereby forge a signature (see [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021000.html bitcoin-dev mailing list post] and [https://github.com/jonasnick/musig2-tweaking writeup] for details). -Checking ''pk'' against ''InvidualPubkey(sk)'' is a simple way to ensure +Checking ''pk'' against ''IndividualPubkey(sk)'' is a simple way to ensure that the secret key provided to ''Sign'' is fully determined already when ''NonceGen'' is invoked. This removes the adversary's ability to influence the secret key after having seen the ''pubnonce'' and thus rules out the attack.Ensuring that the secret key provided to ''Sign'' is fully determined already when ''NonceGen'' is invoked is a simple policy to rule out the attack, diff --git a/bip-0340/test-vectors.py b/bip-0340/test-vectors.py index 317f2ece..9a5a1401 100644 --- a/bip-0340/test-vectors.py +++ b/bip-0340/test-vectors.py @@ -99,7 +99,7 @@ def insecure_schnorr_sign_fixed_nonce(msg, seckey0, k): e = int_from_bytes(tagged_hash("BIP0340/challenge", bytes_from_point(R) + bytes_from_point(P) + msg)) % n return bytes_from_point(R) + bytes_from_int((k + e * seckey) % n) -# Creates a singature with a small x(R) by using k = -1/2 +# Creates a signature with a small x(R) by using k = -1/2 def vector4(): one_half = n - 0x7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a0 seckey = bytes_from_int(0x763758E5CBEEDEE4F7D3FC86F531C36578933228998226672F13C4F0EBE855EB) diff --git a/bip-0345.mediawiki b/bip-0345.mediawiki index a6ead315..bc12f047 100644 --- a/bip-0345.mediawiki +++ b/bip-0345.mediawiki @@ -10,7 +10,7 @@ Type: Standards Track Created: 2023-02-03 License: BSD-3-Clause - Post-History: 2023-01-09: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html [bitcoin-dev] OP_VAULT announcment + Post-History: 2023-01-09: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html [bitcoin-dev] OP_VAULT announcement 2023-03-01: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-March/021510.html [bitcoin-dev] BIP for OP_VAULT diff --git a/bip-0351.mediawiki b/bip-0351.mediawiki index 0a31ca8d..a782b0c8 100644 --- a/bip-0351.mediawiki +++ b/bip-0351.mediawiki @@ -31,7 +31,7 @@ A recipient that wishes to receive funds privately has several options. Each has * The BIP uses a notification mechanism that relies on publicly known per-recipient notification addresses. If Alice wants to send funds to Bob, she has to use the same notification address that everyone else uses to notify Bob. If Alice is not careful with coin selection, i.e. ensuring that her notification UTXO is not linked to her, she will publicly expose herself as someone who is trying to send funds to Bob and their relationship becomes permanently visible on the blockchain. -* The BIP does not say anything about address types. Receiving wallets therefore have to watch all address types that can be created from a single public key. Even then, a sender could send to a script that a receipient cannot spend from. +* The BIP does not say anything about address types. Receiving wallets therefore have to watch all address types that can be created from a single public key. Even then, a sender could send to a script that a recipient cannot spend from. ==Method== @@ -113,7 +113,7 @@ Notifications are performed by publishing transactions that contain a 40-byte x * P)[0..4]'' (4 bytes) * ''Nx'' is the unique public key a sender is using for a particular recipient (33 bytes) -* ''address_type'' is the '''ordinal''' value of a single address type that a sender wants to send to (1 byte). This must be selected from the recepient's accepted address types. +* ''address_type'' is the '''ordinal''' value of a single address type that a sender wants to send to (1 byte). This must be selected from the recipient's accepted address types. When Alice wants to notify Bob that he will receive future payments from her, she performs the following procedure: diff --git a/bip-0352/reference.py b/bip-0352/reference.py index c98dac89..9f43695f 100755 --- a/bip-0352/reference.py +++ b/bip-0352/reference.py @@ -221,7 +221,7 @@ if __name__ == "__main__": ) for input in given["vin"] ] - # Conver the tuples to lists so they can be easily compared to the json list of lists from the given test vectors + # Convert the tuples to lists so they can be easily compared to the json list of lists from the given test vectors input_priv_keys = [] input_pub_keys = [] for vin in vins: diff --git a/bip-0389.mediawiki b/bip-0389.mediawiki index 500d7e3c..72121b74 100644 --- a/bip-0389.mediawiki +++ b/bip-0389.mediawiki @@ -36,7 +36,7 @@ For extended keys and their derivations paths in a Key Expression, BIP 380 state ** Followed by zero or more /NUM or /NUMh path elements indicating BIP 32 derivation steps to be taken after the given extended key. ** Optionally followed by a single /* or /*h final step to denote all direct unhardened or hardened children. -This is modifed to state: +This is modified to state: * xpub encoded extended public key or xprv encoded extended private key (as defined in BIP 32) ** Followed by zero or more /NUM (may be followed by h, H, or ' to indicate a hardened step) path elements indicating BIP 32 derivation steps to be taken after the given extended key.