1
0
mirror of https://github.com/bitcoin/bips.git synced 2025-12-22 14:45:19 +00:00

Merge pull request #1998 from jonatack/2025-10-typo-and-editorial-fixups

Collect and curate various minor fixups from Jul/Aug/Sept
This commit is contained in:
Mark "Murch" Erhardt 2025-10-06 14:38:45 -07:00 committed by GitHub
commit 3d0bab3cc2
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
11 changed files with 21 additions and 21 deletions

View File

@ -95,7 +95,7 @@ In this transaction, there are two inputs, one of 150 BTC and the other of 12 BT
The style of communication is taken directly from PGP/GPG, which uses blocks of ASCII like this to communicate encrypted messages and signatures. This serialization is compact, and will be interpreted the same in all character encodings. It can be copied inline into an email, or saved in a text file. The advantage over the analogous PGP encoding is that there are some human readable elements to it, for users that wish to examine the TxDP packet manually, instead of requiring a program to parse the core elements of the TxDP. The style of communication is taken directly from PGP/GPG, which uses blocks of ASCII like this to communicate encrypted messages and signatures. This serialization is compact, and will be interpreted the same in all character encodings. It can be copied inline into an email, or saved in a text file. The advantage over the analogous PGP encoding is that there are some human readable elements to it, for users that wish to examine the TxDP packet manually, instead of requiring a program to parse the core elements of the TxDP.
A party receiving this TxDP can simply add their signature to the appropriate _TXINPUT_ line. If that is the last signature required, they can broadcast it themselves. Any software that implements this standard should be able to combine multiple TxDPs into a single TxDP. However, even without the programmatic support, a user could manually combine them by copying the appropriate _TXSIGS_ lines between serializations, though it is not the recommended method for combining TxDPs. A party receiving this TxDP can simply add their signature to the appropriate _TXINPUT_ line. If that is the last signature required, they can broadcast it themselves. Any software that implements this standard should be able to combine multiple TxDPs into a single TxDP. However, even without the programmatic support, a user could manually combine them by copying the appropriate _SIG_ lines between serializations, though it is not the recommended method for combining TxDPs.
== Reference Implementation == == Reference Implementation ==

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/>

View File

@ -11,7 +11,7 @@ MAX_BLOCK_SIZE = 1e6
AVG_INTERVAL = 10*60 AVG_INTERVAL = 10*60
TXNS_PER_SEC = 0.5*MAX_BLOCK_SIZE/AVG_TX/AVG_INTERVAL TXNS_PER_SEC = 0.5*MAX_BLOCK_SIZE/AVG_TX/AVG_INTERVAL
MAX_MEMPOOL = MAX_BLOCK_SIZE * 100 MAX_MEMPOOL = MAX_BLOCK_SIZE * 100
COMPRESSABLE = 0.05 COMPRESSIBLE = 0.05
@ -59,7 +59,7 @@ def compressed(rate_multiplier = 1):
block_time = np.random.exponential(AVG_INTERVAL) block_time = np.random.exponential(AVG_INTERVAL)
total_time[i] = block_time total_time[i] = block_time
txns = np.random.poisson(rate_multiplier*get_rate(phase)*block_time) txns = np.random.poisson(rate_multiplier*get_rate(phase)*block_time)
postponed = txns * COMPRESSABLE postponed = txns * COMPRESSIBLE
weight = (txns-postponed)*AVG_TX + backlog weight = (txns-postponed)*AVG_TX + backlog
secondary_backlog += postponed*133 + postponed*34 # Total extra work secondary_backlog += postponed*133 + postponed*34 # Total extra work
if weight > MAX_BLOCK_SIZE: if weight > MAX_BLOCK_SIZE:
@ -88,7 +88,7 @@ if __name__ == "__main__":
compressed_txs2, unspendable2, blocktimes_c2 = compressed(2) compressed_txs2, unspendable2, blocktimes_c2 = compressed(2)
fig, host = plt.subplots() fig, host = plt.subplots()
host.set_title("Transaction Compression Performance with %d%% Adoption During Spike"%(100*COMPRESSABLE)) host.set_title("Transaction Compression Performance with %d%% Adoption During Spike"%(100*COMPRESSIBLE))
fig.subplots_adjust(right=0.75) fig.subplots_adjust(right=0.75)
par1 = host.twinx() par1 = host.twinx()
par2 = host.twinx() par2 = host.twinx()

View File

@ -4,7 +4,7 @@
# be used in production environments. The code is vulnerable to timing attacks, # be used in production environments. The code is vulnerable to timing attacks,
# for example. # for example.
from typing import Any, List, Optional, Tuple, NewType, NamedTuple from typing import List, Optional, Tuple, NewType, NamedTuple
import hashlib import hashlib
import secrets import secrets
import time import time

View File

@ -1,5 +1,7 @@
#!/usr/bin/env python3 #!/usr/bin/env python3
import random
######## ENCODING and DECODING ######## ######## ENCODING and DECODING ########
FIELD_BITS = 32 FIELD_BITS = 32
@ -31,8 +33,6 @@ def sketch(shortids, capacity):
######## DECODING only ######## ######## DECODING only ########
import random
def inv(x): def inv(x):
"""Compute 1/x in GF(2^FIELD_BITS)""" """Compute 1/x in GF(2^FIELD_BITS)"""
t = x t = x
@ -154,4 +154,3 @@ def decode(sketch):
else: else:
sums.append(odd_sums[(i+1)//2]) sums.append(odd_sums[(i+1)//2])
return find_roots(list(reversed(berlekamp_massey(sums)))) return find_roots(list(reversed(berlekamp_massey(sums))))

View File

@ -1,6 +1,5 @@
from typing import Tuple, Optional, Any from typing import Tuple, Optional, Any
import hashlib import hashlib
import binascii
# Set DEBUG to True to get a detailed debug output including # Set DEBUG to True to get a detailed debug output including
# intermediate values during key generation, signing, and # intermediate values during key generation, signing, and

View File

@ -33,7 +33,7 @@ def deser_txid(txid: str):
def deser_compact_size(f: BytesIO): def deser_compact_size(f: BytesIO):
view = f.getbuffer() view = f.getbuffer()
nbytes = view.nbytes; nbytes = view.nbytes
view.release() view.release()
if (nbytes == 0): if (nbytes == 0):
return 0 # end of stream return 0 # end of stream

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.

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 ====

View File

@ -199,7 +199,8 @@ while (++$bipnum <= $topbip) {
die "First Comments-URI must be exactly \"$first_comments_uri\" in $fn" unless $val eq $first_comments_uri; die "First Comments-URI must be exactly \"$first_comments_uri\" in $fn" unless $val eq $first_comments_uri;
} }
} elsif (exists $DateField{$field}) { } elsif (exists $DateField{$field}) {
die "Invalid date format in $fn" unless $val =~ /^20\d{2}\-(?:0\d|1[012])\-(?:[012]\d|30|31)$/; # Enforce date format 20XX-MM-DD, where XX is 00-99, MM is 01-12 and DD is 01-31
die "Invalid date format in $fn" unless $val =~ /^20\d{2}\-(?:0[1-9]|1[0-2])\-(?:0[1-9]|[12]\d|30|31)$/;
} elsif (exists $EmailField{$field}) { } elsif (exists $EmailField{$field}) {
$val =~ m/^(\S[^<@>]*\S) \<[^@>]*\@[\w.]+\.\w+\>$/ or die "Malformed $field line in $fn"; $val =~ m/^(\S[^<@>]*\S) \<[^@>]*\@[\w.]+\.\w+\>$/ or die "Malformed $field line in $fn";
} elsif (not exists $MiscField{$field}) { } elsif (not exists $MiscField{$field}) {

View File

@ -8,7 +8,7 @@
ECODE=0 ECODE=0
for fname in *.mediawiki; do for fname in *.mediawiki; do
GRES=$(grep -n '](http' $fname) GRES=$(grep -n '](http' "$fname")
if [ "$GRES" != "" ]; then if [ "$GRES" != "" ]; then
if [ $ECODE -eq 0 ]; then if [ $ECODE -eq 0 ]; then
>&2 echo "Github Mediawiki format writes link as [URL text], not as [text](url):" >&2 echo "Github Mediawiki format writes link as [URL text], not as [text](url):"