bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-10-13 14:03:47 +00:00
Code Issues Releases Wiki Activity

BIPs 16, 388, 443: typo and editorial fixups

Browse Source 
Co-authored-by: futreall <86553580+futreall@users.noreply.github.com>
This commit is contained in:
Tomás Andróil 2025-08-11 12:22:09 +02:00 committed by Jon Atack
parent a00fb712c5
commit 5d06b3b976
3 changed files with 10 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
bip-0016.mediawiki
View File

@ -58,7 +58,7 @@ Examples:
+3 signature operations: +3 signature operations:
{2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG} {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} {OP_CHECKSIG OP_IF OP_CHECKSIGVERIFY OP_ELSE OP_CHECKMULTISIGVERIFY OP_ENDIF}
==Rationale== ==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: 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 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. # 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. 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]] * [[bip-0016/qa.mediawiki|Quality Assurance test checklist]]
== References == == References ==
<references>
<references/>

8
bip-0388.mediawiki
View File

@ -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: 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 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''). * 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 ==== ==== 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: We set two fundamental design goals:
* Minimize the amount of information that is shown on screen - so that the user can actually validate it. * 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 === === 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 ==== ==== Wallet descriptor template ====
@ -309,7 +309,7 @@ The following descriptor templates are invalid:
* <tt>sh(multi(1,@0/**,@0/**))</tt>: Repeated keys with the same path expression * <tt>sh(multi(1,@0/**,@0/**))</tt>: Repeated keys with the same path expression
* <tt>sh(multi(1,@0/<0;1>/*,@0/<1;2>/*))</tt>: Non-disjoint multipath expressions (<tt>@0/1/*</tt> appears twice) * <tt>sh(multi(1,@0/<0;1>/*,@0/<1;2>/*))</tt>: Non-disjoint multipath expressions (<tt>@0/1/*</tt> appears twice)
* <tt>sh(multi(1,@0/**,xpub6AHA9hZDN11k2ijHMeS5QqHx2KP9aMBRhTDqANMnwVtdyw2TDYRmF8PjpvwUFcL1Et8Hj59S3gTSMcUQ5gAqTz3Wd8EsMTmF3DChhqPQBnU/<0;1>/*))</tt>: Expression with a non-KP key present * <tt>sh(multi(1,@0/**,xpub6AHA9hZDN11k2ijHMeS5QqHx2KP9aMBRhTDqANMnwVtdyw2TDYRmF8PjpvwUFcL1Et8Hj59S3gTSMcUQ5gAqTz3Wd8EsMTmF3DChhqPQBnU/<0;1>/*))</tt>: Expression with a non-KP key present
* <tt>pkh(@0/<0;1;2>/*)</tt>: Solved cardinality > 2 * <tt>pkh(@0/<0;1;2>/*)</tt>: Allowed cardinality > 2
* <tt>tr(musig(@0/**,@1/**))</tt>: Derivation before aggregation is not allowed in wallet policies (despite being allowed in [[bip-0390.mediawiki|BIP-390]]) * <tt>tr(musig(@0/**,@1/**))</tt>: 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. Remark: some of the examples of invalid descriptor templates may be valid via optional extensions.

4
bip-0443.mediawiki
View File

@ -176,7 +176,7 @@ If the <code><data></code> 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. In the following, the ''current input'' is the input whose script is being executed.
The following value of the <code><mode></code> are defined: The following values of the <code><mode></code> are defined:
* <code>CCV_MODE_CHECK_INPUT = -1</code>: Check an input's script; no amount check. * <code>CCV_MODE_CHECK_INPUT = -1</code>: Check an input's script; no amount check.
* <code>CCV_MODE_CHECK_OUTPUT = 0</code>: Check an output's script; preserve the (possibly residual) amount. * <code>CCV_MODE_CHECK_OUTPUT = 0</code>: Check an output's script; preserve the (possibly residual) amount.
* <code>CCV_MODE_CHECK_OUTPUT_IGNORE_AMOUNT = 1</code>: Check an output's script; ignore amounts. * <code>CCV_MODE_CHECK_OUTPUT_IGNORE_AMOUNT = 1</code>: 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. the full amount of the current input.
<source lang="python"> <source lang="python">
residual_input_amount = input[this_input_index].amount residual_input_amount = inputs[this_input_index].amount
</source> </source>
==== <code>OP_CHECKCONTRACTVERIFY</code> evaluation ==== ==== <code>OP_CHECKCONTRACTVERIFY</code> evaluation ====