Skip to content

Support for sending to silent payments #160

Open
@benthecarman

Description

@benthecarman

bitcoin/bips#1458

Supporting receiving for silent payments would be a very large undertaking. However, supporting sending should be relatively pretty trivial.

Tracking issues for SP sending support:

Single party payments:

All inputs are signed by the same entity (MuSig considered here)

Upstream

Local

  • bdk workspace and dependencies upgrade to rust-bitcoin and rust-miniscript with SP support
  • bdk_wallet coin select for SP inputs, single key types (p2wpkh, p2pkh)
  • bdk_wallet coin select for SP inputs, always uses key path spend for TR SP inputs (p2tr key path spend)

Multi party payments and hardware signers:

The inputs should be signed by different entities (e.g. CoinJoin)

Upstream

  • secp256k1 DLEQ module 456
  • rust-libsecp256k1 with DLEQ module 7
  • rust-bitcoin PSBT DLEQ data fields
  • rust-bitcoin upgrade to rust-libsecp256k1 with DLEQ
  • rust-miniscript upgrade to rust-bitcoin with DLEQ support

Local

  • bdk workspace and dependencies upgrade to rust-bitcoin and rust-miniscript with DLEQ support

Extras:

  • RBF support: The removal of any input used to compute a silent payment output, or the addition of any new input included in the BIP 352: Inputs for Shared Secret Derivation requires the re-computation of the silent payment output.
  • TRUC Transactions: Allow wallets without eligible outputs to create silent payment transactions to create a zero fee transaction with a key path spend taproot transaction to create a silent payment output using the first transaction output as input.
  • rust-libsecp256k1 with MuSig2 and FROST support
  • rust-miniscript with MuSig2 and FROST support
  • bdk_wallet coin select for SP inputs, aggregate key types (MuSig2, FROST)

Footnotes

  1. PSBT SP Spec Delving Bitcoin Post

  2. BIP 375 Draft

  3. rust-psbt-v2

  4. DLEQ Spec Github Gist

  5. BlockStream/secp256k1-zkp implementation

  6. BlockStream/secp256k1-zkp implementation exposed for BitBox

  7. NUT12 DLEQ cashubtc/cdk#65 (Cashu Development Kit DLEQ Implementation in Rust)

Metadata

Metadata

Assignees

No one assigned

    Labels

    new featureNew feature or request

    Type

    No type

    Projects

    Status

    Discussion

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions