* Varops: Two BIPs for Script Restoration: varops calculations and tapleaf version (0xc2).
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>
* script restoration: fix MUL cost to account to round up B to word boundary.
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>
* BIP 440, 441: official numbers, into README.mediawiki and renamed.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---------
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
* 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.
