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.
This approach is incompatible with the sys.path extension approach
in the next commit which is used to to find the vendored copy of
secp256k1lab, so use __file__ instead which works as well.
Squashed from the following commits:
- Add skeleton for generating DLEQ proof test vectors
- Add run_test_vectors.py counterpart for generated DLEQ proofs
- Add DLEQ test vectors for proof verification
The `lift_x` function in the BIP and the reference implementation
expect an integer to be passed rather than a byte array.
Can be tested with:
```
$ python3 test-vectors.py > expected.csv
$ diff test-vectors.csv expected.csv
```
Improve the clarity of the BIP w.r.t. pubkeys in the following ways:
- be specific about the purpose of pubkey types in PSBT fields
("plain pubkey" alone doesn't say a lot, especially if it's used
repeatedly within a field)
- replace all uses of "plain pubkey" by "compressed pubkey"
(the only category that should matter is whether the pubkey type
is "x-only" or "plain")
- use consistent word order, e.g. prefer
"compressed aggregate public key" over "aggregate compressed public key"
On some operating systems, Python doesn't provide the expected ripemd160
implementation anymore, so the reference implementation fails to start.
E.g. in Ubuntu 22.04:
----------------------------------------------------------------------------------------------
$ ./reference.py send_and_receive_test_vectors.json
Simple send: two inputs
Traceback (most recent call last):
File "/usr/lib/python3.10/hashlib.py", line 160, in __hash_new
return _hashlib.new(name, data, **kwargs)
ValueError: [digital envelope routines] unsupported
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/thestack/bips/bip-0352/./reference.py", line 228, in <module>
pubkey = get_pubkey_from_input(vin)
File "/home/thestack/bips/bip-0352/./reference.py", line 46, in get_pubkey_from_input
pubkey_hash = hash160(pubkey_bytes)
File "/home/thestack/bips/bip-0352/bitcoin_utils.py", line 130, in hash160
return hashlib.new("ripemd160", hashlib.sha256(s).digest()).digest()
File "/usr/lib/python3.10/hashlib.py", line 166, in __hash_new
return __get_builtin_constructor(name)(data)
File "/usr/lib/python3.10/hashlib.py", line 123, in __get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type ripemd160
----------------------------------------------------------------------------------------------
Fix this by providing a manual implementation, taken from the functional test framework
of Bitcoin Core. See corresponding issue https://github.com/bitcoin/bitcoin/issues/23710 and
PR https://github.com/bitcoin/bitcoin/pull/23716
The first paragraph is taken from BIP-327, with the sentence
about MAJOR version zero removed, as it's not relevant here
(we don't track the pre-merge history).
The input data for the test vector is taken from the signet transaction
fe788cf6578d547819def43d79e6c8f0153d4885f5a343d12bd03f34507aabd6
which spends two P2WPKH inputs with negated pubkeys (x, y) and (x, -y)
from the funding transaction 3a286147b25e16ae80aff406f2673c6e565418c40f45c071245cdebc8a94174e
(see also https://github.com/bitcoin-core/secp256k1/pull/1519#issuecomment-2143167510
and the output from the script in the previous commit message).
Co-authored-by: josibake <josibake@protonmail.com>
The test vector data was generated with a Python script
(see https://github.com/theStack/bitcoin/blob/bc15ea8d0f282908b912dbf62bba816ecd82424d/contrib/silentpayments/submit_input_pubkeys_infinity_tx.py),
leading to the following output:
---------------------------------------------------------------------------------------------------------
Privkey 1: a6df6a0bb448992a301df4258e06a89fe7cf7146f59ac3bd5ff26083acb22ceb
Privkey 2: 592095f44bb766d5cfe20bda71f9575ed2df6b9fb9addc7e5fdffe0923841456
Pubkey 1: 02557ef3e55b0a52489b4454c1169e06bdea43687a69c1f190eb50781644ab6975
Pubkey 2: 03557ef3e55b0a52489b4454c1169e06bdea43687a69c1f190eb50781644ab6975
scriptPubKey 1: 00149d9e24f9fab4e35bf1a6df4b46cb533296ac0792
scriptPubKey 2: 00149860538b5575962776ed0814ae222c7d60c72d7b
Address 1: tb1qnk0zf706kn34hudxma95dj6nx2t2cpujz7j5t5
Address 2: tb1qnps98z64wktzwahdpq22ug3v04svwttm7gs8wn
-> Funding tx submitted: 3a286147b25e16ae80aff406f2673c6e565418c40f45c071245cdebc8a94174e
Taproot output address for spending tx: tb1pqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqkgkkf5
-> Spending tx submitted: fe788cf6578d547819def43d79e6c8f0153d4885f5a343d12bd03f34507aabd6
---------------------------------------------------------------------------------------------------------
For both sender and receiver, generating the input hash is currently
listed as the first step. This already involves summing up the public
keys, even though summing up key material (private keys for sender,
public keys of inputs for receiver) is then again listed explicitly
in later steps.
It seems to be more obvious and less redundant (and also hopefully less
confusing for readers) to reorder the instructions to calculate the
input_hash _after_ the key aggregation is done to reuse the result. In
case of the sender, the private key sum has to be multiplicated with G
in order to the get to the corresponding input pubkey sum.
This also corresponds to the current BIP352 implementation in the
secp256k1 library (https://github.com/bitcoin-core/secp256k1/pull/1519).
The reference implementation in Python here is adapted for the sender
side, the receiver side has already generated the input_hash after
summing up the pubkeys.
This BIP is not in any way connected to the rules of Bitcoin script,
i.e. the "data pushes" term is also not used anywhere and its definition
can hence be removed.
