Julian points out that the implementation does this, which improves accuracy
for the case of small B (since the term is multiplied: for normal OP_ADD etc
we don't bother, since the difference is very bounded).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Special thanks to Murch for teaching me mediawiki, and so much great
formatting and clarity advice.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Ariard mentioned he would like to see a test case for a 64-byte transaction spending a Taproot
output with an annex. I took the opportunity to also make the output be an OP_RETURN with a 2-byte
push, as another semi-realistic transaction.
The test vectors were initially designed to maximally simple, which led to much redundancy. That was
probably too close to one extreme on the spectrum between simplicity and efficiency.
Here we shave off 20k lines by simply representing the header chains as a tree instead of list of
lists by duplicating all common headers.
This is a batch update to the tests vectors for the limit on legacy signature-checking operations
introduced in BIP 54, following feedack received on the Bitcoin Inquisition PR and from Chris
Stewart's implementation in Bitcoin-S.
The paragraph in its entirety is already unambiguous that all signature-checking operations
*present* in the Script (as opposed to *executed*) are counted. However i received feedback that the
"potentially executed" language in the first sentence of this paragraph may be confusing. This is
because it is in theory possible to have a more accurate upper bound by analyzing the possible
spending paths and use the maximum number of signature-checking operations in either to check
against the limit.
This commit rewords the first sentence to use the word "present" to be extra-clear before even
describing how the accounting is performed in later sentences.
* Add sp() output descriptor format for BIP352 Silent Payments
* Update headers and remove space after comma in descriptors
* Add label ranges with examples
* Update with assigned number and adjust preamble for BIP3
* BIP392: Add table entry to README
* Add two argument key expression form and remove birthday and label arguments
* Add BIP392 sp() descriptor to BIP380 script expressions table
* Add sp() descriptor to BIP390 allowed expressions and add musig() example to BIP392
* Add changelog and version header to BIP390
Test case: even though there are 2324 outputs targeted to the recipient,
only 2323 are found due to the introduced K_max limit. Any
implementation following the new BIP protocol rule wouldn't create such
a transaction in the first place, but an attacker might do.
Can be tested by
`$ ./bip-0352/reference.py ./bip-0352/send_and_receive_test_vectors.json`
Test case: as the (only) recipient group contains 2324 addresses and
thus exceeds the K_max limit by one, sending fails.
Can be tested by
`$ ./bip-0352/reference.py ./bip-0352/send_and_receive_test_vectors.json`
Introduce an optional "n_outputs" field as alternative to the detailed
"outputs" objects (the field was already specified, but not used so
far). Also update the documentation of the fields.
In theory this is a backwards incompatible protocol change.
Practically, no existing Silent Payments wallets out there supports
sending to such a high quantity of recipients (not even in terms of
_total_ number of recipients), so the K_max limit should be safe to
introduce, without any negative effects in the wallet ecosystem.
The changes are ported from PR 1705 so that the same public key
terminology is reflected in BIP 174 as well. Please refer this
other PR for more details.
* new bip: timelock recovery storage format
* Comparison with Script-Based Wallets
* Type is Specification
Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>
* Change Authors to a single Author
Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>
* Replace OP_VAULT mention with OP_CHECKCONTRACTVERIFY
* Only the Alert Transaction needs to be non-malleable
* Adding discussion link
* limiting the transactions weight
This is important in order to prevent users from creating
recovery-plans that are hard to propagate.
* Explain anchor-addresses
* fix typo
Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>
* add surname initial to author name
* Explain unintentional initiation of rrecovery-plan.
* limit alert_inputs length to 2439
* updating bip number to 128
* rename to bip-0128.mediawiki
* BIP 128: Timelock-Recovery storage format
* fix field order, change title to uppercase
* Making plugin_version optional
Relevant only in wallets where
the feature is implemented
via a plugin.
* Removing mainnet
Irrelevant. Obviously a monitoring
service for mainnet should
verify that the addresses
are on mainnet.
