diff options
| -rw-r--r-- | .github/workflows/github-action-checks.yml | 9 | ||||
| -rw-r--r-- | .typos.toml | 44 | ||||
| -rw-r--r-- | CONTRIBUTING.md | 12 | ||||
| -rw-r--r-- | bip-0046.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0075.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0119.mediawiki | 4 | ||||
| -rw-r--r-- | bip-0152.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0352.mediawiki | 2 |
8 files changed, 71 insertions, 6 deletions
diff --git a/.github/workflows/github-action-checks.yml b/.github/workflows/github-action-checks.yml index 8a7d2ac..ad76317 100644 --- a/.github/workflows/github-action-checks.yml +++ b/.github/workflows/github-action-checks.yml @@ -20,3 +20,12 @@ jobs: with: fetch-depth: 2 - run: scripts/diffcheck.sh + Typo-Checks: + name: "Typo Checks" + runs-on: ubuntu-latest + steps: + - name: Checkout Actions Repository + uses: actions/checkout@v4 + + - name: Check spelling + uses: crate-ci/typos@master diff --git a/.typos.toml b/.typos.toml new file mode 100644 index 0000000..15d831f --- /dev/null +++ b/.typos.toml @@ -0,0 +1,44 @@ +[default] +extend-ignore-re = [ + # NOTE: use here for regex patterns + "xpub.*", + "xprv.*", + "3.*", # address + "5.*", # address + "private_key .*", + "privkey .*", + "tt.*", # <tt> tags + "code.*", # <code> tags + "\\w*<sub>", # prefix for <sub> tags + "OP_SUCCESSx|\\d+", + "pay.*", + "ser.*", + "prefix.*", + "value: .*", +] + +[default.extend-words] +# NOTE: use here for false-positives +anc = "anc" +PSBT = "PSBT" +ser = "ser" +# Names +Atack = "Atack" +Meni = "Meni" +Ono = "Ono" + +[files] +extend-exclude = [ + "/*/*.csv", + "/*.d*", + "/*/*.d*", + "/*/*.go", + "/*/*.json", + "/*/*/*.json", + "/*/*.mod", + "/*/*.proto", + "/*/*.py", + "scripts", + "/*/*.s*", + "/*/*.t*", +] diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..df6d947 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,12 @@ +# Contributing Guidelines + +Apart from following [BIP 2](./bip-0002.mediawiki), +we do CI checks to ensure that the proposed BIPs do not have common typos. +These checks are done using [`typos`](https://github.com/crate-ci/typos). +To check for typos locally, +install [`typos`](https://github.com/crate-ci/typos) +and then run in the root directory: + +```bash +typos +``` diff --git a/bip-0046.mediawiki b/bip-0046.mediawiki index 1602f81..2bc4039 100644 --- a/bip-0046.mediawiki +++ b/bip-0046.mediawiki @@ -107,7 +107,7 @@ A certificate message can be created by another application external to this sta Almost all wallets implementing this standard can use their already-existing "Sign Message" function to sign the certificate message. As the certificate message itself is always an ASCII string, the wallet may not need to specially implement this section at all but just rely on users copypasting their certificate message into the already-existing "Sign Message" user interface. This works as long as the wallet knows how to use the private key of the timelocked address for signing messages. -It is most important for wallet implementions of this standard to support creating the certificate signature. Verifying the certificate signature is less important. +It is most important for wallet implementations of this standard to support creating the certificate signature. Verifying the certificate signature is less important. == Test vectors == diff --git a/bip-0075.mediawiki b/bip-0075.mediawiki index ebd5b37..5057206 100644 --- a/bip-0075.mediawiki +++ b/bip-0075.mediawiki @@ -219,7 +219,7 @@ message EncryptedProtocolMessage { ==Payment Protocol Process with InvoiceRequests== The full process overview for using '''InvoiceRequests''' in the Payment Protocol is defined below. <br/><br/> -All Payment Protocol messages MUST be encapsulated in either a [[#ProtocolMessage|ProtocolMessage]] or [[#EncryptedProcotolMessage|EncryptedProtocolMessage]]. Once the process begins using [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] messages, all subsequent communications MUST use [[#EncryptedProtocolMessage|EncryptedProtocolMessages]]. +All Payment Protocol messages MUST be encapsulated in either a [[#ProtocolMessage|ProtocolMessage]] or [[#EncryptedProtocolMessage|EncryptedProtocolMessage]]. Once the process begins using [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] messages, all subsequent communications MUST use [[#EncryptedProtocolMessage|EncryptedProtocolMessages]]. <br/><br/> All Payment Protocol messages SHOULD be communicated using [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] encapsulating messages with the exception that an [[#InvoiceRequest|InvoiceRequest]] MAY be communicated using the [[#ProtocolMessage|ProtocolMessage]] if the receiver's public key is unknown. <br/><br/> diff --git a/bip-0119.mediawiki b/bip-0119.mediawiki index be1f70c..6ca0adb 100644 --- a/bip-0119.mediawiki +++ b/bip-0119.mediawiki @@ -392,7 +392,7 @@ transaction preimages. =====Using Non-Tagged Hashes===== The Taproot/Schnorr BIPs use Tagged Hashes -(`SHA256(SHA256(tag)||SHA256(tag)||msg)`) to prevent taproot leafs, branches, +(`SHA256(SHA256(tag)||SHA256(tag)||msg)`) to prevent taproot leaves, branches, tweaks, and signatures from overlapping in a way that might introduce a security [vulnerability https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016091.html]. @@ -494,7 +494,7 @@ The preimage argument passed to CHECKTEMPLATEVERIFY may be unknown or otherwise However, requiring knowledge that an address is spendable from is incompatible with sender's ability to spend to any address (especially, OP_RETURN). If a sender needs to know the template can be spent from before sending, they may request a signature of an provably non-transaction challenge string -from the leafs of the CHECKTEMPLATEVERIFY tree. +from the leaves of the CHECKTEMPLATEVERIFY tree. ====Forwarding Addresses==== diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki index fad1746..eb7d545 100644 --- a/bip-0152.mediawiki +++ b/bip-0152.mediawiki @@ -209,7 +209,7 @@ There are several design goals for the Short ID calculation: * '''Space''' cmpctblock messages are never optional in this protocol, and contain a short ID for each non-prefilled transaction in the block. Thus, the size of short IDs is directly proportional to the maximum bandwidth savings possible. * '''Collision resistance''' It should be hard for network participants to create transactions that cause collisions. If an attacker were able to cause such collisions, filling mempools (and, thus, blocks) with them would cause poor network propagation of new (or non-attacker, in the case of a miner) blocks. -SipHash is a secure, fast, and simple 64-bit MAC designed for network traffic authentication and collision-resistant hash tables. We truncate the output from SipHash-2-4 to 48 bits (see next section) in order to minimize space. The resulting 48-bit hash is certainly not large enough to avoid intentionally created individual collisons, but by using the block hash as a key to SipHash, an attacker cannot predict what keys will be used once their transactions are actually included in a relayed block. We mix in a per-connection 64-bit nonce to obtain independent short IDs on every connection, so that even block creators cannot control where collisions occur, and random collisions only ever affect a small number of connections at any given time. The mixing is done using SHA256(block_header || nonce), which is slow compared to SipHash, but only done once per block. It also adds the ability for nodes to choose the nonce in a better than random way to minimize collisions, though that is not necessary for correct behaviour. Conversely, nodes can also abuse this ability to increase their ability to introduce collisions in the blocks they relay themselves. However, they can already cause more problems by simply refusing to relay blocks. That is inevitable, and this design only seeks to prevent network-wide misbehavior. +SipHash is a secure, fast, and simple 64-bit MAC designed for network traffic authentication and collision-resistant hash tables. We truncate the output from SipHash-2-4 to 48 bits (see next section) in order to minimize space. The resulting 48-bit hash is certainly not large enough to avoid intentionally created individual collisions, but by using the block hash as a key to SipHash, an attacker cannot predict what keys will be used once their transactions are actually included in a relayed block. We mix in a per-connection 64-bit nonce to obtain independent short IDs on every connection, so that even block creators cannot control where collisions occur, and random collisions only ever affect a small number of connections at any given time. The mixing is done using SHA256(block_header || nonce), which is slow compared to SipHash, but only done once per block. It also adds the ability for nodes to choose the nonce in a better than random way to minimize collisions, though that is not necessary for correct behaviour. Conversely, nodes can also abuse this ability to increase their ability to introduce collisions in the blocks they relay themselves. However, they can already cause more problems by simply refusing to relay blocks. That is inevitable, and this design only seeks to prevent network-wide misbehavior. ====Random collision probability==== diff --git a/bip-0352.mediawiki b/bip-0352.mediawiki index 634e179..4462efc 100644 --- a/bip-0352.mediawiki +++ b/bip-0352.mediawiki @@ -99,7 +99,7 @@ In our simplified example we have been referring to Alice's transactions as havi Alice performs the tweak with the sum of her input private keys in the following manner: * Let ''a = a<sub>1</sub> + a<sub>2</sub> + ... + a<sub>n</sub>'' -* Let ''input_hash = hash(outpoint<sub>L</sub> || (a·G))'', where ''outpoint<sub>L</sub>'' is the smallest outpoint lexicographically<ref name="why_smallest_outpoint">'''Why use the lexicographically smallest outpoint for the hash?''' Recall that the purpose of including the input hash is so that the sender and receiver can both come up with a deterministic nonce that ensures that a unique address is generated each time, even when reusing the same scriptPubKey as an input. Choosing the smallest outpoint lexicographically satisifes this requirement, while also ensuring that the generated output is not dependent on the final ordering of inputs in the transaction. Using a single outpoint also works well with memory constrained devices (such as hardware signing devices) as it does not require the device to have the entire transaction in memory in order to generate the silent payment output.</ref> +* Let ''input_hash = hash(outpoint<sub>L</sub> || (a·G))'', where ''outpoint<sub>L</sub>'' is the smallest outpoint lexicographically<ref name="why_smallest_outpoint">'''Why use the lexicographically smallest outpoint for the hash?''' Recall that the purpose of including the input hash is so that the sender and receiver can both come up with a deterministic nonce that ensures that a unique address is generated each time, even when reusing the same scriptPubKey as an input. Choosing the smallest outpoint lexicographically satisfies this requirement, while also ensuring that the generated output is not dependent on the final ordering of inputs in the transaction. Using a single outpoint also works well with memory constrained devices (such as hardware signing devices) as it does not require the device to have the entire transaction in memory in order to generate the silent payment output.</ref> * Let ''P<sub>0</sub> = B + hash(input_hash·a·B || 0)·G'' ''' Spend and Scan Key ''' |