From 5d06b3b976753e397d6b4b8de52a4977bae42722 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tom=C3=A1s=20Andr=C3=B3il?= Date: Mon, 11 Aug 2025 12:22:09 +0200 Subject: [PATCH] BIPs 16, 388, 443: typo and editorial fixups Co-authored-by: futreall <86553580+futreall@users.noreply.github.com> --- bip-0016.mediawiki | 7 ++++--- bip-0388.mediawiki | 8 ++++---- bip-0443.mediawiki | 4 ++-- 3 files changed, 10 insertions(+), 9 deletions(-) diff --git a/bip-0016.mediawiki b/bip-0016.mediawiki index abc27d66..4e8ba139 100644 --- a/bip-0016.mediawiki +++ b/bip-0016.mediawiki @@ -58,7 +58,7 @@ Examples: +3 signature operations: {2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG} -+22 signature operations ++22 signature operations: {OP_CHECKSIG OP_IF OP_CHECKSIGVERIFY OP_ELSE OP_CHECKMULTISIGVERIFY OP_ENDIF} ==Rationale== @@ -74,7 +74,7 @@ The signature operation counting rules are intended to be easy and quick to impl There is a 1-confirmation attack on old implementations, but it is expensive and difficult in practice. The attack is: # Attacker creates a pay-to-script-hash transaction that is valid as seen by old software, but invalid for new implementation, and sends themselves some coins using it. -# Attacker also creates a standard transaction that spends the pay-to-script transaction, and pays the victim who is running old software. +# Attacker also creates a standard transaction that spends the pay-to-script-hash transaction, and pays the victim who is running old software. # Attacker mines a block that contains both transactions. If the victim accepts the 1-confirmation payment, then the attacker wins because both transactions will be invalidated when the rest of the network overwrites the attacker's invalid block. @@ -116,4 +116,5 @@ https://gist.github.com/gavinandresen/3966071 * [[bip-0016/qa.mediawiki|Quality Assurance test checklist]] == References == - + + diff --git a/bip-0388.mediawiki b/bip-0388.mediawiki index adb26cf1..7d3f3d6d 100644 --- a/bip-0388.mediawiki +++ b/bip-0388.mediawiki @@ -35,7 +35,7 @@ This BIP is licensed under the BSD 2-clause license. Unfortunately, descriptors are not a perfect match for the typical usage of hardware signing devices (often also called ''hardware wallets''). Most of them have some of the following limitations when compared to a general-purpose machine running Bitcoin Core: -* they are embedded devices with limited RAM, and computational power; +* they are embedded devices with limited RAM and computational power; * they cannot import additional private keys (that is, they can only sign with keys derived from a single seed via [[bip-0032.mediawiki|BIP-32]]); * they have limited storage, or they might not have persistent storage at all (''stateless design''). @@ -74,7 +74,7 @@ It is out of scope for this document to guarantee that users do not reuse extend ==== UX issues ==== -Miniscript (and taproot trees) allow substantially more complex spending policies. It is a challenge to ensure that the user can practically verify such spending policies per the screen. +Miniscript (and taproot trees) allow substantially more complex spending policies. It is a challenge to ensure that the user can practically verify such spending policies on the screen. We set two fundamental design goals: * Minimize the amount of information that is shown on screen - so that the user can actually validate it. @@ -124,7 +124,7 @@ This section formally defines wallet policies, and how they relate to output scr === Formal definition === -A ''wallet policy'' is composed by a ''wallet descriptor template'', together with a vector of ''key information items''. +A ''wallet policy'' is composed of a ''wallet descriptor template'', together with a vector of ''key information items''. ==== Wallet descriptor template ==== @@ -309,7 +309,7 @@ The following descriptor templates are invalid: * sh(multi(1,@0/**,@0/**)): Repeated keys with the same path expression * sh(multi(1,@0/<0;1>/*,@0/<1;2>/*)): Non-disjoint multipath expressions (@0/1/* appears twice) * sh(multi(1,@0/**,xpub6AHA9hZDN11k2ijHMeS5QqHx2KP9aMBRhTDqANMnwVtdyw2TDYRmF8PjpvwUFcL1Et8Hj59S3gTSMcUQ5gAqTz3Wd8EsMTmF3DChhqPQBnU/<0;1>/*)): Expression with a non-KP key present -* pkh(@0/<0;1;2>/*): Solved cardinality > 2 +* pkh(@0/<0;1;2>/*): Allowed cardinality > 2 * tr(musig(@0/**,@1/**)): Derivation before aggregation is not allowed in wallet policies (despite being allowed in [[bip-0390.mediawiki|BIP-390]]) Remark: some of the examples of invalid descriptor templates may be valid via optional extensions. diff --git a/bip-0443.mediawiki b/bip-0443.mediawiki index aa3879c8..0bcf045b 100644 --- a/bip-0443.mediawiki +++ b/bip-0443.mediawiki @@ -176,7 +176,7 @@ If the is non-empty, then the additive tweak for the data is In the following, the ''current input'' is the input whose script is being executed. -The following value of the are defined: +The following values of the are defined: * CCV_MODE_CHECK_INPUT = -1: Check an input's script; no amount check. * CCV_MODE_CHECK_OUTPUT = 0: Check an output's script; preserve the (possibly residual) amount. * CCV_MODE_CHECK_OUTPUT_IGNORE_AMOUNT = 1: Check an output's script; ignore amounts. @@ -252,7 +252,7 @@ This is executed at the beginning of the evaluation of each input's script. It i the full amount of the current input. - residual_input_amount = input[this_input_index].amount + residual_input_amount = inputs[this_input_index].amount ==== OP_CHECKCONTRACTVERIFY evaluation ====