Support for sending to silent payments #160

Activity

1. LLFourn commented on Sep 11, 2023

   

   LLFourn

   on Sep 11, 2023

   Last edited by LLFourn

   Contributor

   More actions

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

   👍React with 👍1Reacted by 志宇
2. realeinherjar commented on Sep 12, 2023

   

   realeinherjar

   on Sep 12, 2023

   Contributor

   More actions

   This BIP is recent and still with a lot of comments addressing implementation details, e.g. bitcoin/bips#1458 (comment).
3. evanlinjin commented on Sep 15, 2023

   

   evanlinjin

   on Sep 15, 2023

   Member

   More actions

   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.
4. LLFourn commented on Sep 18, 2023

   

   LLFourn

   on Sep 18, 2023

   Contributor

   More actions

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

   👍React with 👍1Reacted by 志宇

   ❤️React with ❤️1Reacted by josie
5. notmandatory

   added

   new featureNew feature or requestNew feature or request

   on Nov 13, 2023
6. notmandatory

   added this to BDK Walleton Nov 13, 2023
7. notmandatory commented on Nov 13, 2023

   

   notmandatory

   on Nov 13, 2023

   Member

   More actions

   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.
8. sethforprivacy commented on May 16, 2024

   

   sethforprivacy

   on May 16, 2024

   Last edited by sethforprivacy

   More actions

   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!

   🚀React with 🚀13Reacted by leonardo, Aaron Jones, Jose Storopoli, M, Benjamin B, Steve Myers, Bonomat, Tankred Hase, Juan Galt, Tony and 3 more
9. sethforprivacy commented on May 17, 2024

   

   sethforprivacy

   on May 17, 2024

   More actions

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

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

   👍React with 👍5Reacted by Riccardo Casatta, Steve Myers, Tony, leonardo and Jacksper13

   🚀React with 🚀4Reacted by Jose Storopoli, Igor Cota, Tony and 志宇
10. storopoli commented on May 22, 2024

    

    storopoli

    on May 22, 2024

    More actions

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

    👍React with 👍3Reacted by 志宇, Seth For Privacy and leonardo

    👀React with 👀1Reacted by Steve Myers
11. notmandatory

    moved this to Discussion in BDK Walleton May 22, 2024
12. junderw commented on Jun 2, 2024

    

    junderw

    on Jun 2, 2024

    More actions

    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.

    ❤️React with ❤️3Reacted by Steve Myers, Jose Storopoli and leonardo
13. cygnet3 commented on Jun 3, 2024

    

    cygnet3

    on Jun 3, 2024

    More actions

    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.
14. junderw commented on Jun 3, 2024

    

    junderw

    on Jun 3, 2024

    More actions

    This should be mitigated in v0.3.0.

    I see you just released this about an hour ago. Nice!
15. notmandatory commented on Aug 13, 2024

    

    notmandatory

    on Aug 13, 2024

    Last edited by notmandatory

    Member

    More actions

    Tracking issues for SP sending support:

    • PSBT SP data fields spec (delving bitcoin post)
    • Discrete Log Equality Proofs spec (github gist)
    • secp256k1 SP modules (SP and DLEQ modules) (Add BIP352 silentpayments module bitcoin-core/secp256k1#1519))
    • rust-libsecp256k1 with SP and DLEQ modules
    • rust-bitcoin SP address types (Silent payments addresses (BIP352) rust-bitcoin/rust-bitcoin#2778)
    • rust-bitcoin PSBT SP data fields
    • rust-bitcoin upgrade to rust-libsecp256k1 with SP and DLEQ
    • rust-miniscript upgrade to rust-bitcoin with SP support
    • bdk workspace and dependencies upgrade to rust-bitcoin and rust-miniscript with SP support
    • bdk_wallet coin select for SP inputs, single key types
    • bdk_wallet coin select for SP inputs, always uses key path spend for TR SP inputs

    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)

    👍React with 👍3Reacted by leonardo, Luis Schwab and Jesus Christ
16. notmandatory commented on Jan 14, 2025

    

    notmandatory

    on Jan 14, 2025

    Member

    More actions

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

    👍React with 👍1Reacted by Seth For Privacy
17. notmandatory

    transferred this issue frombitcoindevkit/bdkon Apr 7, 2025
18. stevenroose commented on Feb 2, 2026

    

    stevenroose

    on Feb 2, 2026

    Contributor

    More actions

    Any update on SP support in BDK?
19. luisschwab commented on Feb 2, 2026

    

    luisschwab

    on Feb 2, 2026

    Member

    More actions

    @stevenroose see the bdk-sp crate.
20. nymius commented on Feb 2, 2026

    

    nymius

    on Feb 2, 2026

    Last edited by nymius

    Contributor

    More actions

    Hello @stevenroose, bdk-sp is an experimental project which demonstrates how to send, how to receive and how to spend silent payment outputs in a very hacky way.
    I developed it as a base to lay down the components needed by a stable implementation to work with BDK, and I'm using it now as a reference.
    SP sending in BDK requires the following:

    1. BIP 375 (psbt support).
    2. BIP 374 (dleq proofs for psbts)
    3. address parsing.
    4. coin selection adapted for silent payments.

    For 1, BIP 375 support has been recently added to rust-psbt.
    For 2, there is a BIP 374 PR which implements the DLEQ proof required by BIP 375.
    For 3, address parsing has been isolated in the feat/full-lib branch from bdk-sp
    An asterisk (*) to all this is that BDK now depends of the bitcoin::psbt crate for its non silentpayment applications, so it has to first move from bitcoin::psbt to rust-psbt.

    Now I'm focusing on (*) and on the coin-selection side (4).

    Consider the libsecp256k1 PR for silent payments isn't merged yet, although we already have rust-bindings for it in rust-bitcoin/rust-secp256k1#876.
    BIP 374 PR has not bindings yet.

    This is key because no implementation will move forward in BDK without the cryptographic support from libsecp256k1.

    👍React with 👍2Reacted by Luis Schwab and Peter
21. nymius commented on Feb 2, 2026

    

    nymius

    on Feb 2, 2026

    Contributor

    More actions

    I've updated the issue with the latest PR references and removed the less accountable steps.

    🚀React with 🚀5Reacted by macgyver, Matthew Ramsden, leonardo, Peter and Mus'ab
22. github-actions commented on Aug 24, 2026

    

    github-actionsBot

    on Aug 24, 2026 – with GitHub Actions

    More actions

    This issue has been inactive for 180 days and labeled stale, comment to keep it open. It will be closed in 30 days if there is no activity.
23. github-actions

    added

    staleAn issue or PR that's considered stale (180d inactivity).An issue or PR that's considered stale (180d inactivity).

    on Aug 24, 2026
24. nymius commented on Aug 24, 2026

    

    nymius

    on Aug 24, 2026

    Contributor

    More actions

    This is in progress.
25. github-actions

    removed

    staleAn issue or PR that's considered stale (180d inactivity).An issue or PR that's considered stale (180d inactivity).

    on Aug 31, 2026
26. startupcompliancekit commented on Oct 30, 2026

    

    startupcompliancekit

    on Oct 30, 2026

    More actions

    @nymius @notmandatory Would a separate contribution covering single-party Silent Payment transaction rebuilding and regression tests fit alongside the ongoing PSBT and coin-selection work?

    Proposed scope: test that changing an eligible input recomputes the Silent Payment output, including fee-bump/RBF cases; cover P2PKH/P2WPKH inputs and Taproot key-path selection; and document the supported boundaries. I would target the active integration branch, with any implementation changes limited to an agreed scope. Any PR would follow the project's signed-commit and testing requirements.

    Before implementation, could you confirm whether this slice is available, the target branch and acceptance checks, and whether the bounty sponsors would allocate a specific BTC amount to it? The public bounty page lists 0.011 BTC for completed sending support; a separately payable portion and current funding have not been confirmed.
27. nymius commented on Oct 30, 2026

    

    nymius

    on Oct 30, 2026

    Contributor

    More actions

    30. Would a separate contribution covering single-party Silent Payment transaction rebuilding

    You mean silent payment transaction building?

    30. and document the supported boundaries. I would target the active integration branch, with any implementation changes limited to an agreed scope.

    This vocabulary is too broad and lacks substance. If you (I'm assuming human) have the knowledge to do it, your PR is welcomed.

    30. Before implementation, could you confirm whether this slice is available, the target branch and acceptance checks, and whether the bounty sponsors would allocate a specific BTC amount to it? The public bounty page lists 0.011 BTC for completed sending support; a separately payable portion and current funding have not been confirmed.

    I'm already working on it. As a new contributor, I would say your time is more valuable reviewing PRs than opening new ones, particularly for those that may overlap with other ongoing efforts.
    I don't represent the person offering the bounty, so I cannot speak of his intentions As far as I understand from the text, the bounty can't be split and the only way to claim it is to provide full sending support through PRs merged in BDK projects.
    As the person championing the silentpayments effort in BDK, I won't engage reviewing PRs that don't consider the current BDK architecture
    in favor of introducing a feature, or which I consider extractive: https://llvm.org/docs/AIToolPolicy.html#extractive-contributions