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>

1 files changed, 52 insertions, 0 deletions

diff --git a/bip-0352.mediawiki b/bip-0352.mediawiki
index 2f8f767..8f41bca 100644
--- a/bip-0352.mediawiki
+++ b/bip-0352.mediawiki
@@ -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.