You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A new transaction builder crate should add an optional feature to enable DNS payment instructions support. If this option is enabled the builder will include a new function to add a recipient via their DNS payment instructions name, i.e. ₿user@domain or user@domain, instead of a bitcoin address.
An error must be thrown if the DNS payment instructions lookup does not return valid payment instructions that include an on-chain address. An error should also be thrown if the user supplied payment amount does not equal the returned payment instructions fixed amount or is not in the min/max range for a configurable amount.
If a DNS payment instructions derived address is used for an output then the PSBT_OUT_DNSSEC_PROOF must also be included in the resulting PSBT.
Use case
This feature will allow a wallet developer to enable paying recipients via their human readable DNS payment instructions name. It will also allow hardware wallets that support BIP353 to validate and display the recipients payment instructions name.
Initially this will only support static on-chain addresses which are likely to be reused and thus be less private. But when BDK is able to support Silent Payments this feature can be used in a way that avoids address reuse.
@sdmg15 sorry I just saw your comment. You don't have to wait for bdk-tx to be finished, you can work on adding this feature on your fork of the latest bdk-tx repo.
Per discussion in dev call today, my thinking now is that this feature probably doesn't need to be directly implemented in bdk_wallet or the new bdk-tx. Instead it could be done first as a new feature in bdk-cli and based on the example there turned into a detailed tutorial in the book-of-bdk for how to use the bitcoin-payment-instructions crate with a BDK based wallet app.
Reacted by Sonkeng, Luis Schwab and Vadim Anufriev
I'd like to close this one as complete since bitcoindevkit/bdk-cli#236 is merged and is a complete example of how to use HRN support with BDK. Ideally we'd have sending to SP address support too, but it will be a small change when that's ready.
Activity
sdmg15 commentedon May 5, 2025
Should we wait for this to be merged ? bitcoindevkit/bdk-tx#1
Was already prototyping something and came across that PR.
I'm also not sure to understand what you mean by "A new transaction builder crate". Shouldn't updating the
tx_builder.rswith a feature flag enough?notmandatory commentedon Dec 1, 2025
@sdmg15 sorry I just saw your comment. You don't have to wait for
bdk-txto be finished, you can work on adding this feature on your fork of the latestbdk-txrepo.sdmg15 commentedon Dec 2, 2025
Alright, the PR I was referring to in the comment was merged in the meantime. Anyway working to get a draft PR for this in the next few days.
notmandatory commentedon Dec 2, 2025
Great! I put your name on this issue so others know you're working on it.
notmandatory commentedon Dec 16, 2025
Per discussion in dev call today, my thinking now is that this feature probably doesn't need to be directly implemented in
bdk_walletor the newbdk-tx. Instead it could be done first as a new feature inbdk-cliand based on the example there turned into a detailed tutorial in the book-of-bdk for how to use thebitcoin-payment-instructionscrate with a BDK based wallet app.github-actions commentedon Oct 12, 2026
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.
notmandatory commentedon Oct 13, 2026
I'd like to close this one as complete since bitcoindevkit/bdk-cli#236 is merged and is a complete example of how to use HRN support with BDK. Ideally we'd have sending to SP address support too, but it will be a small change when that's ready.
sdmg15 commentedon Oct 13, 2026
Yes we can go ahead and close this one.