Silent payment support

[jvgelder]

While working on bitcoinjs silent payment support bip352 I stumbled upon this repo as it already implements psbtv2.
Might be interesting to also implement it here for devs that already depend on this stack.

Some example are already out there:

• https://github.com/BlueWallet/SilentPayments/blob/master/src/index.ts
• Blind bit with PSBT: https://github.com/setavenger/blindbit-wallet-cli/blob/dc555fb7ce2d6cb79f38a8444bfd518e91e35c70/pkg/wallet/send.go#L316
• Sparrow: https://github.com/sparrowwallet/drongo/tree/master/src/main/java/com/sparrowwallet/drongo/silentpayments
• https://github.com/cygnet3/rust-silentpayments
  -Bip375 example implementation : https://github.com/macgyver13/bips/tree/bip375-reference-testvectors/bip-0375

I was working on something here bitcoinjs/bitcoinjs-lib#2269 but it needs bip370, 375 and a merge in rust-bitcoin/rust-secp256k1#876 and https://github.com/bitcoinjs/tiny-secp256k1 to become useful

My suggestion would be to split it up in:

• Creating SP addresses
• Sending to SP addresses
• Receiving on SP address (due to different choices in scanning models eg tweak data, taproot data, full scan etc)
• Parallel you could implement bip353 using https://github.com/TheBlueMatt/dnssec-prover/tree/master/wasmpack

[bucko13]

Awesome suggestion! I love this idea and would be happy to back adding support.

Receiving to SP addresses might be a bit tough. caravan coordinator doesn't have taproot wallet support and it's not really on our road map (not that I'm against it, but it's quite complex not the highest priority for our use cases). Address creation, parsing, sending and PSBT support though would definitely be valuable and achievable.

[jvgelder]

Receiving to SP addresses might be a bit tough. caravan coordinator doesn't have taproot wallet support and it's not really on our road map (not that I'm against it, but it's quite complex not the highest priority for our use cases). Address creation, parsing, sending and PSBT support though would definitely be valuable and achievable.

Nice sending does require us to be able to create taproot outputs it should be doable for sending. Similar to how it was implemented in https://github.com/BlueWallet/SilentPayments.

[bucko13]

We've had spend to taproot for a year or two now so shouldn't be an issue there!

[jvgelder]

Explored a bit what we need to do if we only want to support sending.

We would have to add the following field to the PSBT as per bip375

• PSBT_OUT_SP_V0_INFO (containing the decoded pub scan and spend key)
• PSBT_GLOBAL_SP_ECDH_SHARE ( storing the share for each given public scan key)

We would need to add the following functionality on the PSBT:

• For signing PSBTs that contain silentpayments Add DLEQ proof verification https://github.com/bitcoin/bips/blob/master/bip-0375.mediawiki#signer
• For the extractor add output script calculation https://github.com/bitcoin/bips/blob/master/bip-0375.mediawiki#computing-the-output-scripts

We would need to be able to decode SP addresses:

• Add decoding in bitcoin-address-validation note we need to extend using LIMIT as sp addresses contain scan and spend keys.
• Add sp and sp to prefix in address.ts

From the requirements of output calculation we probably need custom tagged hash:

• BIP0352/Inputs — for input hash
• BIP0352/SharedSecret — for output key tweaking)

Optionally if we want to support multiple signers:

• Add for constructor and updater PSBT_IN_SP_DLEQ (optionally if we want to support multiple signers)
• Combiner Merge per-input ECDH shares and DLEQ proofs from multiple PSBTs

1. Depending on the input type used in this repo (I can't find it?) we may want to push for some calculations to be added to bitcoinjs?
2. PSBTv2 doesn't exist in bitcoinjs yet so it makes sense to add anything related to PSBT to the caravan package directly (altought I am working on a PSBTv2 package that hopefully can be part of bitcoinjs some day).

[bucko13]

Sounds good to me! We have fully self-contained psbt v2 implementation in caravan-psbt so that's where I would start. Adding directly would definitely be preferable in part because with our v2 library we're trying to reduce dependencies as much as possible.

I'm not sure what you mean by "input type" but everything in caravan is built around multisig, so p2sh, p2wsh and nested p2wsh are the script types that we support for inputs. You can see some of that throughout caravan-bitcoin (maybe here is a good place to start).

[jvgelder]

With input type I meant the structure that is used to add inputs but i guess there is no type other than this? (There is no TxInput interface):

{
    previousTxId,
    outputIndex,
    sequence,
    nonWitnessUtxo,
    witnessUtxo,
    redeemScript,
    witnessScript,
    bip32Derivation,
    sighashType,
  }: {
    previousTxId: Buffer | string;
    outputIndex: number;
    sequence?: number;
    nonWitnessUtxo?: Buffer;
    witnessUtxo?: { amount: number; script: Buffer };
    redeemScript?: Buffer;
    witnessScript?: Buffer;
    bip32Derivation?: {
      pubkey: Buffer;
      masterFingerprint: Buffer;
      path: string;
    }[];
    sighashType?: SighashType;
  }

Il create a basic PR the coming weeks so you can comment if the direction I am heading is the correct one.

1. Starting with the fields specified by https://github.com/bitcoin/bips/blob/master/bip-0375.mediawiki
2. Later adding silent payment address encoding decoding (note this is an intermittent address from which a taproot output will be calculated). Need to figure out where to add this or whether it should be a separate file.
3. Update addOutput and addInput to adhere to https://github.com/bitcoin/bips/blob/master/bip-0375.mediawiki#constructor
4. As the silentpayment output script depends on inputs, we need to figure out where and how we do the final output script calculation ? do we recalculate each time we add or remove an input?

[jvgelder]

Created a pr let me know if that is a kind of structure that might work.
I split up the PR in several commits so hopefully its a bit easier to scan/review some of the mundane stuff.