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.
* Add Chaincode Delegation BIP
* Update license to BSD-3-Clause and expand blinded signing documentation
* Address initial PR comments
* Update with BIP number assignment
* Fix delegator_sign test vector
* Upgrade secp256k1lab and add license file
- Upgrade vendored secp256k1lab to commit a265da1 (adds type annotations)
- Add COPYING file to satisfy MIT license requirements
- Document secp256k1lab commit reference in BIP text
* Fix type checker and linter issues in reference implementation
- Fix TweakContext to use Scalar types for gacc/tacc
- Replace HashFunction enum with Callable type alias
- Fix bytearray to bytes conversion in blind_sign
- Move imports to top of file
- Fix boolean comparison style (use 'not' instead of '== False')
- Add proper type annotations and casts for dict handling
- Remove unused imports and type ignore comments
* Address PR review comments on terminology and clarity
- Add intro explaining delegation naming (chain code is delegated, not
signing authority)
- Reorder terminology to list Delegator before Delegatee
- Replace "quorum" with clearer "can co-sign for UTXOs" language
- Clarify derivation constraints in terms of delegatee's extended key
- Rename "Delegatee Signing" section to "Signing Modes"
- Fix "delegatee can apply" to "delegator can produce" (line 112)
- Replace undefined "caller" with "delegatee" (line 173)
- Clarify "Change outputs" to "Tweaks for change outputs" (line 98)
- Add note that message is separate from CCD bundle
- Add note on application-specific verification (addresses, amounts)
- Add transition sentence clarifying non-concurrent protocol scope
* Add changelog entry for 0.1.3
* Fix header: use Authors (plural) for multiple authors
* Fix BIP header format for CI compliance
- Change Type from 'Standards Track' to 'Specification' (valid type)
- Change 'Created' to 'Assigned' (correct field name per BIP format)
- Change 'Post-History' to 'Discussion' (recognized field in buildtable.pl)
* Apply suggestion from @murchandamus
---------
Co-authored-by: Jesse Posner <jesse.posner@gmail.com>
