mirror of
https://github.com/bitcoin/bips.git
synced 2026-05-25 17:09:34 +00:00
Add reference.py with test vectors
* reference.py contains the silent payment specific code * secp256k1.py for doing the EC operations * bech32m.py contains code for encoding/decoding bech32(m) addresses * bitcoin_utils.py contains some helper code, not specific to silent payments * send_and_receive_test_vectors.json contains the wallet unit test vectors Co-Authored-By: S3RK <1466284+S3RK@users.noreply.github.com> Co-Authored-By: Oghenovo Usiwoma <37949128+Eunovo@users.noreply.github.com> Co-authored-by: S.Blagogee <34041358+setavenger@users.noreply.github.com>
This commit is contained in:
@@ -370,6 +370,58 @@ If using a seed/seed phrase only style backup, the user can recover the wallet's
|
||||
|
||||
Silent payments introduces a new address format and protocol for sending and as such is not compatible with older wallet software or wallets which have not implemented the silent payments protocol.
|
||||
|
||||
== Test Vectors ==
|
||||
|
||||
A [[bip-0352/send_and_receive_test_vectors.json|collection of test vectors in JSON format]] are provided, along with a [[bip-0352/reference.py|python reference implementation]]. Each test vector consists of a sending test case and corresponding receiving test case. This is to allow sending and receiving to be implemented separately. To ensure determinism while testing, sort the array of ''B<sub>m</sub>'' by amount (see the [[bip-0352/reference.py|reference implementation]]). Test cases use the following schema:
|
||||
|
||||
''' test_case '''
|
||||
|
||||
{
|
||||
"comment": "Comment describing the behavior being tested",
|
||||
"sending": [<array of sender test objects>],
|
||||
"receiving": [<array of recipient test objects>],
|
||||
}
|
||||
|
||||
''' sender '''
|
||||
|
||||
{
|
||||
"given": {
|
||||
"vin": [<array of vin objects with an added field for the private key. These objects are structured to match the `vin` output field from `getrawtransaction verbosity=2`>],
|
||||
"recipients": [<array of strings, where each string is a bech32m encoding representing a silent payment address>]
|
||||
},
|
||||
"expected": {
|
||||
"outputs": [<array of strings, where each string is a hex encoding of 32-byte X-only public key; contains all possible output sets, test must match a subset of size `n_outputs`>],
|
||||
"n_outouts": <integer for the exact number of expected outputs>,
|
||||
},
|
||||
}
|
||||
|
||||
''' recipient '''
|
||||
|
||||
{
|
||||
"given": {
|
||||
"vin": [<array of vin objects. These objects are structured to match the `vin` output field from `getrawtransaction verbosity=2`>],
|
||||
"key_material": {
|
||||
"scan_priv_key": <hex encoded scan private key>,
|
||||
"spend_priv_key": <hex encoded spend private key>,
|
||||
}
|
||||
"labels": [<array of ints, representing labels the receiver has used>],
|
||||
},
|
||||
"expected": {
|
||||
"addresses": [<array of bech32m strings, one for the silent payment address and each labeled address (if used)>],
|
||||
"outputs": [<array of outputs with tweak and signature; contains all possible output sets, tester must match a subset of size `n_outputs`>
|
||||
{
|
||||
"priv_key_tweak": <hex encoded private key tweak data>,
|
||||
"pub_key": <hex encoded X-only public key>,
|
||||
"signature": <hex encoded signature for the output (produced with spend_priv_key + priv_key_tweak)>
|
||||
},
|
||||
...
|
||||
],
|
||||
"n_outputs": <integer for the exact number of expected outputs>
|
||||
}
|
||||
}
|
||||
|
||||
Wallets should include inputs not in the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' list when testing to ensure that only inputs from the list are being used for shared secret derivation. Additionally, receiving wallets should include non-silent payment outputs for themselves in testing to ensure silent payments scanning does not interfere with regular outputs detection.
|
||||
|
||||
=== Functional tests ===
|
||||
|
||||
Below is a list of functional tests which should be included in sending and receiving implementations.
|
||||
|
||||
Reference in New Issue
Block a user