Silent Payments: Sending (take 2) #35302

eef27eb07e silentpayments: skip slow benchmarks for low iters count (<= 2)
53c37e4f4c docs: update README
93a1170501 ci: enable silentpayments module
ab849cf045 tests: add sha256 tag test
15ee7158ee tests: add constant time tests
da3ca4bdcb tests: add BIP-352 test vectors
e2ead23724 silentpayments: optimize scanning by using batch inversion
0655c15024 silentpayments: add benchmarks for scanning
e62f412878 silentpayments: add examples/silentpayments.c
7493c37b9f silentpayments: respect per-group recipients protocol limit (K_max=2323)
5f90295d56 silentpayments: receiving
9a55346925 silentpayments: recipient label support
b97aafd655 silentpayments: sending
8fe6ab62a2 build: add skeleton for new silentpayments (BIP352) module

git-subtree-dir: src/secp256k1
git-subtree-split: eef27eb07e6537e559d5dc4c9c98923bfc267766

Add a method for passing a KeyPair object to secp256k1 functions expecting a secp256k1_keypair.
This allows for passing a KeyPair directly to a secp256k1 function without needing to create a
temporary secp256k1_keypair object.

Add V0SilentPaymentsDestination and UnknownSilentPaymentsDestination
for v1 to v30; Bip352 reserves v31 for a backwards incompatible change.
v1 to v30 addresses are handled as specified in Bip352. The extra_data
will be ignored during sending.

Valid v0 and v1 addresses were added to key_io_valid.json for testing,
and invalid v0 and a v31 address were added to key_io_invalid.json.

V0SilentPaymentsDestination must not be formed from invalid public keys;
the operations that must be performed to send to a V0SilentPaymentsDestination,
require valid public keys. Hence, the V0SilentPaymentsDestination struct takes
the following precautions to ensure that such invalid states are not possible:
- The constructor will throw when provided with invalid public keys
- The public keys are private and const references can be retrieved using member functions.

Wrap the silentpayments module from libsecp256k1. This is placed in
common as it is intended to be used by:

  * RPCs: for parsing addresses
  * Wallet: for sending, receiving, spending silent payments outputs
  * Node: for creating silent payments indexes for light clients

Have `IsValidDestination` return false for silent payments destinations
and set an error string when decoding a silent payments address.

This prevents anyone from sending to a silent payments address before
sending is implemented in the wallet, but also allows the functions to
be used in the unit testing famework.

Use the test vectors to test sending and receiving. A few cases are not
covered here, namely anything that requires testing specific to the
wallet. For example:

* Taproot script path spending is not tested, as that is better tested in
  a wallets coin selection / signing logic
* Re-computing outputs during RBF is not tested, as that is better
  tested in a wallets RBF logic

The unit tests are written in such a way that adding new test cases is
as easy as updating the JSON file

BIP352 v0 specifies that a silent payment output is a taproot output.
Taproot scriptPubKeys are a fixed size, so when calculating the
serialized size for a CRecipient with a V0SilentPayments destination,
use WitnessV1Taproot for the serialized txout size.

Add a method for retreiving a private key for a given scriptPubKey.
If the scriptPubKey is a taproot output, tweak the private key with the
merkle root or hash of the public key, if applicable.

Add a flag to the `CoinControl` object if silent payments destinations
are provided. Before adding the flag, call a function which checks if:

* The wallet has private keys
* The wallet is unlocked

Without both of the above being true, we cannot send to a silent payment
address.

During coin selection, if this flag is set, skip taproot inputs when
script spend data is available. This is based on the assumption that if
a user provides script spend data, they don't have access to the key
path spend. As future improvement, we could instead check to see if we
have access to the key path spend, and only exclude the output when we
don't regardless of whether or not the user provides script spend data.

Also skip UTXOs of type `WITNESS_UNKNOWN`, although it is very unlikely
our wallet would ever try to spend a witness unknown output.

The coin selection algorithm wasn't guaranteed
to return a set of coins that are eligible for silent
payments transactions even when eligible coins
were available.

This commit forces coin selection to first select
eligible coins before attempting to complete
the result set with ineligible coins.

If the transaction cannot be fulfilled with only
eligible coins, coin selection will "preset" eligible
outputs in descending order of `effective_value`
and attempt to construct a selection from the
remaining available coins.

`CreateSilentPaymentsOutputs` gets the correct private keys, adds them
together, groups the silent payments destinations and then generates the
taproot script pubkeys. These are then passed back to
CreateTransactionInternal, which uses these scriptPubKeys to update
vecSend before adding them to the transaction outputs.

If sending to a silent payments dest, the change type should be taproot
because silent payments dests appear as taproot outputs on the blockchain.

Treat silent payments addresses as valid destination. Also disable using
silent payments addresses with the `addr()` descriptor, as this
descriptor expects an encoding of a scriptPubKey, whereas a silent
payment address consists of instructions on how to generate a
scriptPubKey for the recipient.

Co-authored-by: Novo <eunovo9@gmail.com>

Handle sp addresses that may be supplied in the `outputs` param of `bumpfee` and `psbtbumpfee`.

The outputs must be passed as CTxDestinations rather than scriptPubKeys to `CreateRateBumpTransaction`,
so `CreateTransaction` can properly transform the provided sp addresses to taproot scriptPubKeys.

Useful in sp sending functional tests to check that the resulting taproot outputs are correct.