Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for sending to silent payments #1114

Open
20 tasks
Tracked by #76
benthecarman opened this issue Sep 9, 2023 · 13 comments
Open
20 tasks
Tracked by #76

Support for sending to silent payments #1114

benthecarman opened this issue Sep 9, 2023 · 13 comments
Labels
module-wallet new feature New feature or request

Comments

@benthecarman
Copy link
Contributor

benthecarman commented Sep 9, 2023

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)

@LLFourn
Copy link
Contributor

LLFourn commented Sep 11, 2023

Although sending has less moving parts I'm less sure what's the right API inside transaction building system (mostly because we haven't re-designed transaction building yet). With receiving I know precisely how to approach it (as a new tx graph index) so I'd be tempted to do receiving first and leave sending until later. Of course the basic function to produce a silent payment tx would be needed at the same time as the receiving code which would allow you to manually construct a silent payment tx. We could consider upstreaming this to rust-bitcoin also.

This would go all go in bdk_chain with bdk_tx_build proving more user friendly API coming later (when it exists).

@realeinherjar
Copy link
Contributor

This BIP is recent and still with a lot of comments addressing implementation details, e.g. bitcoin/bips#1458 (comment).

@evanlinjin
Copy link
Member

This BIP is recent and still with a lot of comments addressing implementation details, e.g. bitcoin/bips#1458 (comment).

I think Steven was mostly addressing HOW the BIP should be structured, not WHAT was specified in the BIP.

@LLFourn
Copy link
Contributor

LLFourn commented Sep 18, 2023

While implementing it we might be able to contribute to the BIP if we find places it could be improved.

@notmandatory notmandatory added the new feature New feature or request label Nov 13, 2023
@notmandatory notmandatory added this to the 1.1.0-alpha.0 milestone Nov 13, 2023
@notmandatory
Copy link
Member

I assigned this to the 1.1 alpha release, but we may need to move it to 2.0 depending on priorities and who's available/able to work on this.

@notmandatory notmandatory removed this from the 1.1.0 milestone Mar 18, 2024
@sethforprivacy
Copy link

sethforprivacy commented May 16, 2024

Traction behind Silent Payments is rapidly growing, with two wallets releasing with full Silent Payments support this week. The most important step for their traction to continue is that wallets simply add the ability to send to Silent Payment addresses (as this PR is for) so that there is proper incentive for receiving to be added to wallets, exchanges, etc.

I started a bounty for this PR to be completed on X, and am offering 100k sats to the dev who's PR solves this issue (total bounty of 870k sats thanks to others on X).

Would be amazing for all BDK wallets to be able to trivially enable sending to Silent Payment addresses!

@sethforprivacy
Copy link

Note that a crate for Silent Payment support already exists here:

https://github.com/cygnet3/rust-silentpayments

@storopoli
Copy link
Contributor

The parsing of a SP address is being discussed upstream here rust-bitcoin/rust-bitcoin#2778

@notmandatory notmandatory moved this to Discussion in BDK Wallet May 22, 2024
@junderw
Copy link

junderw commented Jun 2, 2024

I think this should wait for

  1. Add BIP352 silentpayments module bitcoin-core/secp256k1#1519
  2. merging 1 into the secp256k1 wrapper crate.

rust-silentpayments crate is a great prototype, but it is weak to timing attacks.

@cygnet3
Copy link

cygnet3 commented Jun 3, 2024

rust-silentpayments crate is a great prototype, but it is weak to timing attacks.

This should be mitigated in v0.3.0. If you find other weaknesses or oversights, please let us know!

Having said that, I agree that the purpose of rust-silentpayments is somewhat obsolete once the silentpayments module is added to secp256k1. Perhaps we will transition to become a more high-level silent payments utility library. Either way, we will rewrite rust-silentpayments to work on top of the silentpayments module once that is finalized.

@junderw
Copy link

junderw commented Jun 3, 2024

This should be mitigated in v0.3.0.

I see you just released this about an hour ago. Nice!

@notmandatory
Copy link
Member

notmandatory commented Aug 13, 2024

Tracking issues for SP sending support:

Related issues

  • 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)

@notmandatory
Copy link
Member

I moved the above tracking checklist to the description of this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
module-wallet new feature New feature or request
Projects
Status: Discussion
Development

No branches or pull requests

9 participants