Add experimental silent payment transaction creation support by nymius · Pull Request #220 · bitcoindevkit/bdk-cli

nymius · 2025-09-10T19:39:09Z

Description

This PR adds experimental support for creating silent payment transactions through a new CreateSpTx command. The implementation integrates the bdk_sp crate to enable sending Bitcoin to silent payment addresses.

Key changes:

Adds bdk_sp dependency as an optional feature
Implements CreateSpTx command with support for silent payment recipients
Includes parser for silent payment address:amount pairs
Returns signed transactions ready for broadcast (not PSBTs due to silent payment derivation constraints)

Notes to the reviewers

This feature is marked as EXPERIMENTAL and includes warnings against mainnet use
The command returns signed transactions directly rather than PSBTs because silent payment script pubkey derivation cannot be performed securely in a trustless manner with standard PSBT workflows
RBF is disabled for silent payment transactions (sequence set to MAX)
The implementation handles both single key and extended key signers
Error handling uses temporary .expect() calls that should be addressed in future iterations

Changelog notice

Added: Experimental silent payment transaction creation via CreateSpTx command (feature-gated behind sp flag)

Checklists

All Submissions

I've signed all my commits
I followed the conventional commit guidelines
I ran cargo fmt, clippy and test before committing

New Features

* [ ] I've added tests for the new feature

I've added docs for the new feature

tvpeter

Thank you for working on adding this feature @nymius,

I couldn't test because I don't know how to construct sp recipients. I will check the documentation on the library and will come back to test it. In the meantime, I have left some comments.
Thank you

tvpeter

Thank you for working on this feature @nymius

I left a few comments.

Pls remember to rebase too.

sdmg15

tested ACK.

Script to use to reproduce

export NETWORK=regtest
export EXT_DESCRIPTOR='wpkh(tprv8ZgxMBicQKsPdMzWj9KHvoExKJDqfZFuT5D8o9XVZ3wfyUcnPNPJKncq5df8kpDWnMxoKbGrpS44VawHG17ZSwTkdhEtVRzSYXd14vDYXKw/0/*)'export INT_DESCRIPTOR='wpkh(tprv8ZgxMBicQKsPdMzWj9KHvoExKJDqfZFuT5D8o9XVZ3wfyUcnPNPJKncq5df8kpDWnMxoKbGrpS44VawHG17ZSwTkdhEtVRzSYXd14vDYXKw/1/*)'export DATABASE_TYPE="sqlite"export CLIENT_TYPE="rpc"export SERVER_URL="http://127.0.0.1:18443"export COOKIE="/home/user/.bitcoin/regtest/.cookie"export SP_RECIPIENT="sprt1qqdu4udd7wz7flf89m27teqzp8gxzvgpg3xudw89c0ce0f0pe0gwz6qkc4d7dg587w9rkaa0cj8rf3c28z0g45tgn0t7fzkk4s867w3eugga03ret"
raw_tx=$(cargo run -- wallet create_sp_tx --to-sp $SP_RECIPIENT:1000 | jq -r '.raw_tx'| tr -d '\n')
cargo run --features rpc -- wallet broadcast --tx $raw_tx

sdmg15 · 2026-03-16T11:22:23Z

+ let _resigned = wallet.sign(&mut psbt, SignOptions::default())?;

+ let raw_tx = psbt.extract_tx()?;
+ if cli_opts.pretty {


Here to actually make this "pretty", there's is this shorten function that can be used. I'm not though convinced if that's helpful for users wanting to copy the full raw tx maybe they should just not use the pretty format.

Good point, I'm not sure about the use cases of the pretty flag, but I'm against shortening the transaction.

nymius · 2026-03-18T19:34:03Z

I've addressed the pending comments:

Checked the finalization status of the PSBT after the signing phase before silent payment output derivation.
Implemented logic to handle the drain to silent payment case.

I've also:

Changed the feature flag sp to silent-payments for more clarity.
Squashed all commits into a single one.

codecov · 2026-03-18T19:36:21Z

Codecov Report

❌ Patch coverage is 0.55866% with 178 lines in your changes missing coverage. Please review.
✅ Project coverage is 10.22%. Comparing base (07fd32f) to head (c579854).
⚠️ Report is 7 commits behind head on master.

Files with missing lines	Patch %	Lines
src/handlers.rs	0.61%	162 Missing ⚠️
src/utils.rs	0.00%	16 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## master #220 +/- ##
==========================================
- Coverage 11.13% 10.22% -0.91% 
==========================================
Files 8 8 Lines 2488 2709 +221 ==========================================
Hits 277 277 - Misses 2211 2432 +221

Flag	Coverage Δ
rust	`10.22% <0.55%> (-0.91%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

sdmg15 · 2026-04-22T14:25:13Z

reACK 516af1b

tvpeter

tACK 516af1b

Well done @nymius, I have left a few nits for you.

Also, my final thoughts:
i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?
i) Since createtx and createsptx are almost similar, it would be great to merge createsptx into the existing createtx to improve the UX for users, but allow the fn to detect an SP address and handle it internally. This can be in another PR.

- Adds CreateSpTx command to create transactions with silent payment outputs: this command creates signed transactions directly rather than PSBTs due to current limitations in secure shared derivation. It supports mixed recipients: regular addresses + silent payments. It DOES NOT support RBF for the created transactions. It generates signed transactions ready for broadcasting. - Adds SilentPaymentCode command to create silent payment codes from public keys and network: the silent payment code generated is independent from any of the other stateful features of bdk-cli. This command is mainly intended for experimental use, do not lock any funds to the generated code if you don't know what you are doing and don't have the keys matching the public keys used. - Adds bdk_sp dependency with "silent-payments" feature flag. - Adds silent payment recipient parsing utility. - Add README section for new silent payment commands. Note: This is experimental functionality for testing only, not recommended for mainnet use. Signed-off-by: nymius <155548262+nymius@users.noreply.github.com>

nymius · 2026-05-11T14:02:12Z

Also, my final thoughts: i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?

I'm not sure I follow you here. The current implementation works with multiple SP codes or with a single one repeated multiple times. Do you mean if I have tested explicitly with bdk-cli? I can check it again.

i) Since createtx and createsptx are almost similar, it would be great to merge createsptx into the existing createtx to improve the UX for users, but allow the fn to detect an SP address and handle it internally. This can be in another PR.

The idea of keeping them separated is that is easier to remove this command and replace it by a more mature silent payment sending command later. But we can work the details in another Issue/PR.

tvpeter · 2026-05-11T15:28:13Z

Also, my final thoughts: i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?
I'm not sure I follow you here. The current implementation works with multiple SP codes or with a single one repeated multiple times. Do you mean if I have tested explicitly with bdk-cli? I can check it again.

The latter is what I am referring to; a single user can send more than one output to the same SP code e.g

... create_sp_tx --to-sp tsp1q...mh:5000 --to-sp tsp1q...mh:3000

I don't know whether this is considered key reuse. That is why I called your attention to check if it is acceptable.

nymius · 2026-05-11T15:34:44Z

Also, my final thoughts: i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?
I'm not sure I follow you here. The current implementation works with multiple SP codes or with a single one repeated multiple times. Do you mean if I have tested explicitly with bdk-cli? I can check it again.
The latter is what I am referring to; a single user can send more than one output to the same SP code e.g
... create_sp_tx --to-sp tsp1q...mh:5000 --to-sp tsp1q...mh:3000
I don't know whether this is considered key reuse. That is why I called your attention to check if it is acceptable.

That's one of the features from silent payments, you can reuse the same silent payment code in the transaction and you're going to get two different output scripts. Have you checked the outputs of the transactions? The one corresponding to the 5000 amount did look similar to the one sending 3000 sats?

tvpeter · 2026-05-11T15:43:30Z

That's one of the features from silent payments, you can reuse the same silent payment code in the transaction and you're going to get two different output scripts.

Alright then, that's fine.

Have you checked the outputs of the transactions? The one corresponding to the 5000 amount did look similar to the one sending 3000 sats?

I did not run it now; I ran it during my last test. I will inspect the output after I test shortly.

tvpeter

tACK c579854

Thank you for adding this feature @nymius.

I have now confirmed that it indeed produced different outputs.

nymius · 2025-09-10T19:39:09Z

Description

This PR adds experimental support for creating silent payment transactions through a new CreateSpTx command. The implementation integrates the bdk_sp crate to enable sending Bitcoin to silent payment addresses.

Key changes:

Adds bdk_sp dependency as an optional feature
Implements CreateSpTx command with support for silent payment recipients
Includes parser for silent payment address:amount pairs
Returns signed transactions ready for broadcast (not PSBTs due to silent payment derivation constraints)

Notes to the reviewers

This feature is marked as EXPERIMENTAL and includes warnings against mainnet use
The command returns signed transactions directly rather than PSBTs because silent payment script pubkey derivation cannot be performed securely in a trustless manner with standard PSBT workflows
RBF is disabled for silent payment transactions (sequence set to MAX)
The implementation handles both single key and extended key signers
Error handling uses temporary .expect() calls that should be addressed in future iterations

Changelog notice

Added: Experimental silent payment transaction creation via CreateSpTx command (feature-gated behind sp flag)

Checklists

All Submissions

I've signed all my commits
I followed the conventional commit guidelines
I ran cargo fmt, clippy and test before committing

New Features

* [ ] I've added tests for the new feature

I've added docs for the new feature

tvpeter

Thank you for working on adding this feature @nymius,

I couldn't test because I don't know how to construct sp recipients. I will check the documentation on the library and will come back to test it. In the meantime, I have left some comments.
Thank you

tvpeter

Thank you for working on this feature @nymius

I left a few comments.

Pls remember to rebase too.

sdmg15

tested ACK.

Script to use to reproduce

export NETWORK=regtest
export EXT_DESCRIPTOR='wpkh(tprv8ZgxMBicQKsPdMzWj9KHvoExKJDqfZFuT5D8o9XVZ3wfyUcnPNPJKncq5df8kpDWnMxoKbGrpS44VawHG17ZSwTkdhEtVRzSYXd14vDYXKw/0/*)'export INT_DESCRIPTOR='wpkh(tprv8ZgxMBicQKsPdMzWj9KHvoExKJDqfZFuT5D8o9XVZ3wfyUcnPNPJKncq5df8kpDWnMxoKbGrpS44VawHG17ZSwTkdhEtVRzSYXd14vDYXKw/1/*)'export DATABASE_TYPE="sqlite"export CLIENT_TYPE="rpc"export SERVER_URL="http://127.0.0.1:18443"export COOKIE="/home/user/.bitcoin/regtest/.cookie"export SP_RECIPIENT="sprt1qqdu4udd7wz7flf89m27teqzp8gxzvgpg3xudw89c0ce0f0pe0gwz6qkc4d7dg587w9rkaa0cj8rf3c28z0g45tgn0t7fzkk4s867w3eugga03ret"
raw_tx=$(cargo run -- wallet create_sp_tx --to-sp $SP_RECIPIENT:1000 | jq -r '.raw_tx'| tr -d '\n')
cargo run --features rpc -- wallet broadcast --tx $raw_tx

sdmg15 · 2026-03-16T11:22:23Z

+ let _resigned = wallet.sign(&mut psbt, SignOptions::default())?;

+ let raw_tx = psbt.extract_tx()?;
+ if cli_opts.pretty {


Here to actually make this "pretty", there's is this shorten function that can be used. I'm not though convinced if that's helpful for users wanting to copy the full raw tx maybe they should just not use the pretty format.

Good point, I'm not sure about the use cases of the pretty flag, but I'm against shortening the transaction.

nymius · 2026-03-18T19:34:03Z

I've addressed the pending comments:

Checked the finalization status of the PSBT after the signing phase before silent payment output derivation.
Implemented logic to handle the drain to silent payment case.

I've also:

Changed the feature flag sp to silent-payments for more clarity.
Squashed all commits into a single one.

codecov · 2026-03-18T19:36:21Z

Codecov Report

❌ Patch coverage is 0.55866% with 178 lines in your changes missing coverage. Please review.
✅ Project coverage is 10.22%. Comparing base (07fd32f) to head (c579854).
⚠️ Report is 7 commits behind head on master.

Files with missing lines	Patch %	Lines
src/handlers.rs	0.61%	162 Missing ⚠️
src/utils.rs	0.00%	16 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## master #220 +/- ##
==========================================
- Coverage 11.13% 10.22% -0.91% 
==========================================
Files 8 8 Lines 2488 2709 +221 ==========================================
Hits 277 277 - Misses 2211 2432 +221

Flag	Coverage Δ
rust	`10.22% <0.55%> (-0.91%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

sdmg15 · 2026-04-22T14:25:13Z

reACK 516af1b

tvpeter

tACK 516af1b

Well done @nymius, I have left a few nits for you.

Also, my final thoughts:
i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?
i) Since createtx and createsptx are almost similar, it would be great to merge createsptx into the existing createtx to improve the UX for users, but allow the fn to detect an SP address and handle it internally. This can be in another PR.

- Adds CreateSpTx command to create transactions with silent payment outputs: this command creates signed transactions directly rather than PSBTs due to current limitations in secure shared derivation. It supports mixed recipients: regular addresses + silent payments. It DOES NOT support RBF for the created transactions. It generates signed transactions ready for broadcasting. - Adds SilentPaymentCode command to create silent payment codes from public keys and network: the silent payment code generated is independent from any of the other stateful features of bdk-cli. This command is mainly intended for experimental use, do not lock any funds to the generated code if you don't know what you are doing and don't have the keys matching the public keys used. - Adds bdk_sp dependency with "silent-payments" feature flag. - Adds silent payment recipient parsing utility. - Add README section for new silent payment commands. Note: This is experimental functionality for testing only, not recommended for mainnet use. Signed-off-by: nymius <155548262+nymius@users.noreply.github.com>

nymius · 2026-05-11T14:02:12Z

Also, my final thoughts: i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?

I'm not sure I follow you here. The current implementation works with multiple SP codes or with a single one repeated multiple times. Do you mean if I have tested explicitly with bdk-cli? I can check it again.

i) Since createtx and createsptx are almost similar, it would be great to merge createsptx into the existing createtx to improve the UX for users, but allow the fn to detect an SP address and handle it internally. This can be in another PR.

The idea of keeping them separated is that is easier to remove this command and replace it by a more mature silent payment sending command later. But we can work the details in another Issue/PR.

tvpeter · 2026-05-11T15:28:13Z

Also, my final thoughts: i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?
I'm not sure I follow you here. The current implementation works with multiple SP codes or with a single one repeated multiple times. Do you mean if I have tested explicitly with bdk-cli? I can check it again.

The latter is what I am referring to; a single user can send more than one output to the same SP code e.g

... create_sp_tx --to-sp tsp1q...mh:5000 --to-sp tsp1q...mh:3000

I don't know whether this is considered key reuse. That is why I called your attention to check if it is acceptable.

nymius · 2026-05-11T15:34:44Z

Also, my final thoughts: i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?
I'm not sure I follow you here. The current implementation works with multiple SP codes or with a single one repeated multiple times. Do you mean if I have tested explicitly with bdk-cli? I can check it again.
The latter is what I am referring to; a single user can send more than one output to the same SP code e.g
... create_sp_tx --to-sp tsp1q...mh:5000 --to-sp tsp1q...mh:3000
I don't know whether this is considered key reuse. That is why I called your attention to check if it is acceptable.

That's one of the features from silent payments, you can reuse the same silent payment code in the transaction and you're going to get two different output scripts. Have you checked the outputs of the transactions? The one corresponding to the 5000 amount did look similar to the one sending 3000 sats?

tvpeter · 2026-05-11T15:43:30Z

That's one of the features from silent payments, you can reuse the same silent payment code in the transaction and you're going to get two different output scripts.

Alright then, that's fine.

Have you checked the outputs of the transactions? The one corresponding to the 5000 amount did look similar to the one sending 3000 sats?

I did not run it now; I ran it during my last test. I will inspect the output after I test shortly.

tvpeter

tACK c579854

Thank you for adding this feature @nymius.

I have now confirmed that it indeed produced different outputs.

nymius · 2025-09-10T19:39:09Z

Description

This PR adds experimental support for creating silent payment transactions through a new CreateSpTx command. The implementation integrates the bdk_sp crate to enable sending Bitcoin to silent payment addresses.

Key changes:

Adds bdk_sp dependency as an optional feature
Implements CreateSpTx command with support for silent payment recipients
Includes parser for silent payment address:amount pairs
Returns signed transactions ready for broadcast (not PSBTs due to silent payment derivation constraints)

Notes to the reviewers

This feature is marked as EXPERIMENTAL and includes warnings against mainnet use
The command returns signed transactions directly rather than PSBTs because silent payment script pubkey derivation cannot be performed securely in a trustless manner with standard PSBT workflows
RBF is disabled for silent payment transactions (sequence set to MAX)
The implementation handles both single key and extended key signers
Error handling uses temporary .expect() calls that should be addressed in future iterations

Changelog notice

Added: Experimental silent payment transaction creation via CreateSpTx command (feature-gated behind sp flag)

Checklists

All Submissions

I've signed all my commits
I followed the conventional commit guidelines
I ran cargo fmt, clippy and test before committing

New Features

* [ ] I've added tests for the new feature

I've added docs for the new feature

tvpeter

Thank you for working on adding this feature @nymius,

I couldn't test because I don't know how to construct sp recipients. I will check the documentation on the library and will come back to test it. In the meantime, I have left some comments.
Thank you

tvpeter

Thank you for working on this feature @nymius

I left a few comments.

Pls remember to rebase too.

sdmg15

tested ACK.

Script to use to reproduce

export NETWORK=regtest
export EXT_DESCRIPTOR='wpkh(tprv8ZgxMBicQKsPdMzWj9KHvoExKJDqfZFuT5D8o9XVZ3wfyUcnPNPJKncq5df8kpDWnMxoKbGrpS44VawHG17ZSwTkdhEtVRzSYXd14vDYXKw/0/*)'export INT_DESCRIPTOR='wpkh(tprv8ZgxMBicQKsPdMzWj9KHvoExKJDqfZFuT5D8o9XVZ3wfyUcnPNPJKncq5df8kpDWnMxoKbGrpS44VawHG17ZSwTkdhEtVRzSYXd14vDYXKw/1/*)'export DATABASE_TYPE="sqlite"export CLIENT_TYPE="rpc"export SERVER_URL="http://127.0.0.1:18443"export COOKIE="/home/user/.bitcoin/regtest/.cookie"export SP_RECIPIENT="sprt1qqdu4udd7wz7flf89m27teqzp8gxzvgpg3xudw89c0ce0f0pe0gwz6qkc4d7dg587w9rkaa0cj8rf3c28z0g45tgn0t7fzkk4s867w3eugga03ret"
raw_tx=$(cargo run -- wallet create_sp_tx --to-sp $SP_RECIPIENT:1000 | jq -r '.raw_tx'| tr -d '\n')
cargo run --features rpc -- wallet broadcast --tx $raw_tx

sdmg15 · 2026-03-16T11:22:23Z

+ let _resigned = wallet.sign(&mut psbt, SignOptions::default())?;

+ let raw_tx = psbt.extract_tx()?;
+ if cli_opts.pretty {


Here to actually make this "pretty", there's is this shorten function that can be used. I'm not though convinced if that's helpful for users wanting to copy the full raw tx maybe they should just not use the pretty format.

Good point, I'm not sure about the use cases of the pretty flag, but I'm against shortening the transaction.

nymius · 2026-03-18T19:34:03Z

I've addressed the pending comments:

Checked the finalization status of the PSBT after the signing phase before silent payment output derivation.
Implemented logic to handle the drain to silent payment case.

I've also:

Changed the feature flag sp to silent-payments for more clarity.
Squashed all commits into a single one.

codecov · 2026-03-18T19:36:21Z

Codecov Report

❌ Patch coverage is 0.55866% with 178 lines in your changes missing coverage. Please review.
✅ Project coverage is 10.22%. Comparing base (07fd32f) to head (c579854).
⚠️ Report is 7 commits behind head on master.

Files with missing lines	Patch %	Lines
src/handlers.rs	0.61%	162 Missing ⚠️
src/utils.rs	0.00%	16 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## master #220 +/- ##
==========================================
- Coverage 11.13% 10.22% -0.91% 
==========================================
Files 8 8 Lines 2488 2709 +221 ==========================================
Hits 277 277 - Misses 2211 2432 +221

Flag	Coverage Δ
rust	`10.22% <0.55%> (-0.91%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

sdmg15 · 2026-04-22T14:25:13Z

reACK 516af1b

tvpeter

tACK 516af1b

Well done @nymius, I have left a few nits for you.

Also, my final thoughts:
i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?
i) Since createtx and createsptx are almost similar, it would be great to merge createsptx into the existing createtx to improve the UX for users, but allow the fn to detect an SP address and handle it internally. This can be in another PR.

- Adds CreateSpTx command to create transactions with silent payment outputs: this command creates signed transactions directly rather than PSBTs due to current limitations in secure shared derivation. It supports mixed recipients: regular addresses + silent payments. It DOES NOT support RBF for the created transactions. It generates signed transactions ready for broadcasting. - Adds SilentPaymentCode command to create silent payment codes from public keys and network: the silent payment code generated is independent from any of the other stateful features of bdk-cli. This command is mainly intended for experimental use, do not lock any funds to the generated code if you don't know what you are doing and don't have the keys matching the public keys used. - Adds bdk_sp dependency with "silent-payments" feature flag. - Adds silent payment recipient parsing utility. - Add README section for new silent payment commands. Note: This is experimental functionality for testing only, not recommended for mainnet use. Signed-off-by: nymius <155548262+nymius@users.noreply.github.com>

nymius · 2026-05-11T14:02:12Z

Also, my final thoughts: i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?

I'm not sure I follow you here. The current implementation works with multiple SP codes or with a single one repeated multiple times. Do you mean if I have tested explicitly with bdk-cli? I can check it again.

i) Since createtx and createsptx are almost similar, it would be great to merge createsptx into the existing createtx to improve the UX for users, but allow the fn to detect an SP address and handle it internally. This can be in another PR.

The idea of keeping them separated is that is easier to remove this command and replace it by a more mature silent payment sending command later. But we can work the details in another Issue/PR.

tvpeter · 2026-05-11T15:28:13Z

Also, my final thoughts: i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?
I'm not sure I follow you here. The current implementation works with multiple SP codes or with a single one repeated multiple times. Do you mean if I have tested explicitly with bdk-cli? I can check it again.

The latter is what I am referring to; a single user can send more than one output to the same SP code e.g

... create_sp_tx --to-sp tsp1q...mh:5000 --to-sp tsp1q...mh:3000

I don't know whether this is considered key reuse. That is why I called your attention to check if it is acceptable.

nymius · 2026-05-11T15:34:44Z

Also, my final thoughts: i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?
I'm not sure I follow you here. The current implementation works with multiple SP codes or with a single one repeated multiple times. Do you mean if I have tested explicitly with bdk-cli? I can check it again.
The latter is what I am referring to; a single user can send more than one output to the same SP code e.g
... create_sp_tx --to-sp tsp1q...mh:5000 --to-sp tsp1q...mh:3000
I don't know whether this is considered key reuse. That is why I called your attention to check if it is acceptable.

That's one of the features from silent payments, you can reuse the same silent payment code in the transaction and you're going to get two different output scripts. Have you checked the outputs of the transactions? The one corresponding to the 5000 amount did look similar to the one sending 3000 sats?

tvpeter · 2026-05-11T15:43:30Z

That's one of the features from silent payments, you can reuse the same silent payment code in the transaction and you're going to get two different output scripts.

Alright then, that's fine.

Have you checked the outputs of the transactions? The one corresponding to the 5000 amount did look similar to the one sending 3000 sats?

I did not run it now; I ran it during my last test. I will inspect the output after I test shortly.

tvpeter

tACK c579854

Thank you for adding this feature @nymius.

I have now confirmed that it indeed produced different outputs.

nymius · 2025-09-10T19:39:09Z

Description

This PR adds experimental support for creating silent payment transactions through a new CreateSpTx command. The implementation integrates the bdk_sp crate to enable sending Bitcoin to silent payment addresses.

Key changes:

Adds bdk_sp dependency as an optional feature
Implements CreateSpTx command with support for silent payment recipients
Includes parser for silent payment address:amount pairs
Returns signed transactions ready for broadcast (not PSBTs due to silent payment derivation constraints)

Notes to the reviewers

This feature is marked as EXPERIMENTAL and includes warnings against mainnet use
The command returns signed transactions directly rather than PSBTs because silent payment script pubkey derivation cannot be performed securely in a trustless manner with standard PSBT workflows
RBF is disabled for silent payment transactions (sequence set to MAX)
The implementation handles both single key and extended key signers
Error handling uses temporary .expect() calls that should be addressed in future iterations

Changelog notice

Added: Experimental silent payment transaction creation via CreateSpTx command (feature-gated behind sp flag)

Checklists

All Submissions

I've signed all my commits
I followed the conventional commit guidelines
I ran cargo fmt, clippy and test before committing

New Features

* [ ] I've added tests for the new feature

I've added docs for the new feature

tvpeter

Thank you for working on adding this feature @nymius,

I couldn't test because I don't know how to construct sp recipients. I will check the documentation on the library and will come back to test it. In the meantime, I have left some comments.
Thank you

tvpeter

Thank you for working on this feature @nymius

I left a few comments.

Pls remember to rebase too.

sdmg15

tested ACK.

Script to use to reproduce

export NETWORK=regtest
export EXT_DESCRIPTOR='wpkh(tprv8ZgxMBicQKsPdMzWj9KHvoExKJDqfZFuT5D8o9XVZ3wfyUcnPNPJKncq5df8kpDWnMxoKbGrpS44VawHG17ZSwTkdhEtVRzSYXd14vDYXKw/0/*)'export INT_DESCRIPTOR='wpkh(tprv8ZgxMBicQKsPdMzWj9KHvoExKJDqfZFuT5D8o9XVZ3wfyUcnPNPJKncq5df8kpDWnMxoKbGrpS44VawHG17ZSwTkdhEtVRzSYXd14vDYXKw/1/*)'export DATABASE_TYPE="sqlite"export CLIENT_TYPE="rpc"export SERVER_URL="http://127.0.0.1:18443"export COOKIE="/home/user/.bitcoin/regtest/.cookie"export SP_RECIPIENT="sprt1qqdu4udd7wz7flf89m27teqzp8gxzvgpg3xudw89c0ce0f0pe0gwz6qkc4d7dg587w9rkaa0cj8rf3c28z0g45tgn0t7fzkk4s867w3eugga03ret"
raw_tx=$(cargo run -- wallet create_sp_tx --to-sp $SP_RECIPIENT:1000 | jq -r '.raw_tx'| tr -d '\n')
cargo run --features rpc -- wallet broadcast --tx $raw_tx

sdmg15 · 2026-03-16T11:22:23Z

+ let _resigned = wallet.sign(&mut psbt, SignOptions::default())?;

+ let raw_tx = psbt.extract_tx()?;
+ if cli_opts.pretty {


Here to actually make this "pretty", there's is this shorten function that can be used. I'm not though convinced if that's helpful for users wanting to copy the full raw tx maybe they should just not use the pretty format.

Good point, I'm not sure about the use cases of the pretty flag, but I'm against shortening the transaction.

nymius · 2026-03-18T19:34:03Z

I've addressed the pending comments:

Checked the finalization status of the PSBT after the signing phase before silent payment output derivation.
Implemented logic to handle the drain to silent payment case.

I've also:

Changed the feature flag sp to silent-payments for more clarity.
Squashed all commits into a single one.

codecov · 2026-03-18T19:36:21Z

Codecov Report

❌ Patch coverage is 0.55866% with 178 lines in your changes missing coverage. Please review.
✅ Project coverage is 10.22%. Comparing base (07fd32f) to head (c579854).
⚠️ Report is 7 commits behind head on master.

Files with missing lines	Patch %	Lines
src/handlers.rs	0.61%	162 Missing ⚠️
src/utils.rs	0.00%	16 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## master #220 +/- ##
==========================================
- Coverage 11.13% 10.22% -0.91% 
==========================================
Files 8 8 Lines 2488 2709 +221 ==========================================
Hits 277 277 - Misses 2211 2432 +221

Flag	Coverage Δ
rust	`10.22% <0.55%> (-0.91%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

sdmg15 · 2026-04-22T14:25:13Z

reACK 516af1b

tvpeter

tACK 516af1b

Well done @nymius, I have left a few nits for you.

Also, my final thoughts:
i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?
i) Since createtx and createsptx are almost similar, it would be great to merge createsptx into the existing createtx to improve the UX for users, but allow the fn to detect an SP address and handle it internally. This can be in another PR.

- Adds CreateSpTx command to create transactions with silent payment outputs: this command creates signed transactions directly rather than PSBTs due to current limitations in secure shared derivation. It supports mixed recipients: regular addresses + silent payments. It DOES NOT support RBF for the created transactions. It generates signed transactions ready for broadcasting. - Adds SilentPaymentCode command to create silent payment codes from public keys and network: the silent payment code generated is independent from any of the other stateful features of bdk-cli. This command is mainly intended for experimental use, do not lock any funds to the generated code if you don't know what you are doing and don't have the keys matching the public keys used. - Adds bdk_sp dependency with "silent-payments" feature flag. - Adds silent payment recipient parsing utility. - Add README section for new silent payment commands. Note: This is experimental functionality for testing only, not recommended for mainnet use. Signed-off-by: nymius <155548262+nymius@users.noreply.github.com>

nymius · 2026-05-11T14:02:12Z

Also, my final thoughts: i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?

I'm not sure I follow you here. The current implementation works with multiple SP codes or with a single one repeated multiple times. Do you mean if I have tested explicitly with bdk-cli? I can check it again.

i) Since createtx and createsptx are almost similar, it would be great to merge createsptx into the existing createtx to improve the UX for users, but allow the fn to detect an SP address and handle it internally. This can be in another PR.

The idea of keeping them separated is that is easier to remove this command and replace it by a more mature silent payment sending command later. But we can work the details in another Issue/PR.

tvpeter · 2026-05-11T15:28:13Z

Also, my final thoughts: i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?
I'm not sure I follow you here. The current implementation works with multiple SP codes or with a single one repeated multiple times. Do you mean if I have tested explicitly with bdk-cli? I can check it again.

The latter is what I am referring to; a single user can send more than one output to the same SP code e.g

... create_sp_tx --to-sp tsp1q...mh:5000 --to-sp tsp1q...mh:3000

I don't know whether this is considered key reuse. That is why I called your attention to check if it is acceptable.

nymius · 2026-05-11T15:34:44Z

Also, my final thoughts: i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?
I'm not sure I follow you here. The current implementation works with multiple SP codes or with a single one repeated multiple times. Do you mean if I have tested explicitly with bdk-cli? I can check it again.
The latter is what I am referring to; a single user can send more than one output to the same SP code e.g
... create_sp_tx --to-sp tsp1q...mh:5000 --to-sp tsp1q...mh:3000
I don't know whether this is considered key reuse. That is why I called your attention to check if it is acceptable.

That's one of the features from silent payments, you can reuse the same silent payment code in the transaction and you're going to get two different output scripts. Have you checked the outputs of the transactions? The one corresponding to the 5000 amount did look similar to the one sending 3000 sats?

tvpeter · 2026-05-11T15:43:30Z

That's one of the features from silent payments, you can reuse the same silent payment code in the transaction and you're going to get two different output scripts.

Alright then, that's fine.

Have you checked the outputs of the transactions? The one corresponding to the 5000 amount did look similar to the one sending 3000 sats?

I did not run it now; I ran it during my last test. I will inspect the output after I test shortly.

tvpeter

tACK c579854

Thank you for adding this feature @nymius.

I have now confirmed that it indeed produced different outputs.

nymius · 2025-09-10T19:39:09Z

Description

This PR adds experimental support for creating silent payment transactions through a new CreateSpTx command. The implementation integrates the bdk_sp crate to enable sending Bitcoin to silent payment addresses.

Key changes:

Adds bdk_sp dependency as an optional feature
Implements CreateSpTx command with support for silent payment recipients
Includes parser for silent payment address:amount pairs
Returns signed transactions ready for broadcast (not PSBTs due to silent payment derivation constraints)

Notes to the reviewers

This feature is marked as EXPERIMENTAL and includes warnings against mainnet use
The command returns signed transactions directly rather than PSBTs because silent payment script pubkey derivation cannot be performed securely in a trustless manner with standard PSBT workflows
RBF is disabled for silent payment transactions (sequence set to MAX)
The implementation handles both single key and extended key signers
Error handling uses temporary .expect() calls that should be addressed in future iterations

Changelog notice

Added: Experimental silent payment transaction creation via CreateSpTx command (feature-gated behind sp flag)

Checklists

All Submissions

I've signed all my commits
I followed the conventional commit guidelines
I ran cargo fmt, clippy and test before committing

New Features

* [ ] I've added tests for the new feature

I've added docs for the new feature

tvpeter

Thank you for working on adding this feature @nymius,

I couldn't test because I don't know how to construct sp recipients. I will check the documentation on the library and will come back to test it. In the meantime, I have left some comments.
Thank you

tvpeter

Thank you for working on this feature @nymius

I left a few comments.

Pls remember to rebase too.

sdmg15

tested ACK.

Script to use to reproduce

export NETWORK=regtest
export EXT_DESCRIPTOR='wpkh(tprv8ZgxMBicQKsPdMzWj9KHvoExKJDqfZFuT5D8o9XVZ3wfyUcnPNPJKncq5df8kpDWnMxoKbGrpS44VawHG17ZSwTkdhEtVRzSYXd14vDYXKw/0/*)'export INT_DESCRIPTOR='wpkh(tprv8ZgxMBicQKsPdMzWj9KHvoExKJDqfZFuT5D8o9XVZ3wfyUcnPNPJKncq5df8kpDWnMxoKbGrpS44VawHG17ZSwTkdhEtVRzSYXd14vDYXKw/1/*)'export DATABASE_TYPE="sqlite"export CLIENT_TYPE="rpc"export SERVER_URL="http://127.0.0.1:18443"export COOKIE="/home/user/.bitcoin/regtest/.cookie"export SP_RECIPIENT="sprt1qqdu4udd7wz7flf89m27teqzp8gxzvgpg3xudw89c0ce0f0pe0gwz6qkc4d7dg587w9rkaa0cj8rf3c28z0g45tgn0t7fzkk4s867w3eugga03ret"
raw_tx=$(cargo run -- wallet create_sp_tx --to-sp $SP_RECIPIENT:1000 | jq -r '.raw_tx'| tr -d '\n')
cargo run --features rpc -- wallet broadcast --tx $raw_tx

sdmg15 · 2026-03-16T11:22:23Z

+ let _resigned = wallet.sign(&mut psbt, SignOptions::default())?;

+ let raw_tx = psbt.extract_tx()?;
+ if cli_opts.pretty {


Here to actually make this "pretty", there's is this shorten function that can be used. I'm not though convinced if that's helpful for users wanting to copy the full raw tx maybe they should just not use the pretty format.

Good point, I'm not sure about the use cases of the pretty flag, but I'm against shortening the transaction.

nymius · 2026-03-18T19:34:03Z

I've addressed the pending comments:

Checked the finalization status of the PSBT after the signing phase before silent payment output derivation.
Implemented logic to handle the drain to silent payment case.

I've also:

Changed the feature flag sp to silent-payments for more clarity.
Squashed all commits into a single one.

codecov · 2026-03-18T19:36:21Z

Codecov Report

❌ Patch coverage is 0.55866% with 178 lines in your changes missing coverage. Please review.
✅ Project coverage is 10.22%. Comparing base (07fd32f) to head (c579854).
⚠️ Report is 7 commits behind head on master.

Files with missing lines	Patch %	Lines
src/handlers.rs	0.61%	162 Missing ⚠️
src/utils.rs	0.00%	16 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## master #220 +/- ##
==========================================
- Coverage 11.13% 10.22% -0.91% 
==========================================
Files 8 8 Lines 2488 2709 +221 ==========================================
Hits 277 277 - Misses 2211 2432 +221

Flag	Coverage Δ
rust	`10.22% <0.55%> (-0.91%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

sdmg15 · 2026-04-22T14:25:13Z

reACK 516af1b

tvpeter

tACK 516af1b

Well done @nymius, I have left a few nits for you.

Also, my final thoughts:
i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?
i) Since createtx and createsptx are almost similar, it would be great to merge createsptx into the existing createtx to improve the UX for users, but allow the fn to detect an SP address and handle it internally. This can be in another PR.

- Adds CreateSpTx command to create transactions with silent payment outputs: this command creates signed transactions directly rather than PSBTs due to current limitations in secure shared derivation. It supports mixed recipients: regular addresses + silent payments. It DOES NOT support RBF for the created transactions. It generates signed transactions ready for broadcasting. - Adds SilentPaymentCode command to create silent payment codes from public keys and network: the silent payment code generated is independent from any of the other stateful features of bdk-cli. This command is mainly intended for experimental use, do not lock any funds to the generated code if you don't know what you are doing and don't have the keys matching the public keys used. - Adds bdk_sp dependency with "silent-payments" feature flag. - Adds silent payment recipient parsing utility. - Add README section for new silent payment commands. Note: This is experimental functionality for testing only, not recommended for mainnet use. Signed-off-by: nymius <155548262+nymius@users.noreply.github.com>

nymius · 2026-05-11T14:02:12Z

Also, my final thoughts: i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?

I'm not sure I follow you here. The current implementation works with multiple SP codes or with a single one repeated multiple times. Do you mean if I have tested explicitly with bdk-cli? I can check it again.

i) Since createtx and createsptx are almost similar, it would be great to merge createsptx into the existing createtx to improve the UX for users, but allow the fn to detect an SP address and handle it internally. This can be in another PR.

The idea of keeping them separated is that is easier to remove this command and replace it by a more mature silent payment sending command later. But we can work the details in another Issue/PR.

tvpeter · 2026-05-11T15:28:13Z

Also, my final thoughts: i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?
I'm not sure I follow you here. The current implementation works with multiple SP codes or with a single one repeated multiple times. Do you mean if I have tested explicitly with bdk-cli? I can check it again.

The latter is what I am referring to; a single user can send more than one output to the same SP code e.g

... create_sp_tx --to-sp tsp1q...mh:5000 --to-sp tsp1q...mh:3000

I don't know whether this is considered key reuse. That is why I called your attention to check if it is acceptable.

nymius · 2026-05-11T15:34:44Z

Also, my final thoughts: i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?
I'm not sure I follow you here. The current implementation works with multiple SP codes or with a single one repeated multiple times. Do you mean if I have tested explicitly with bdk-cli? I can check it again.
The latter is what I am referring to; a single user can send more than one output to the same SP code e.g
... create_sp_tx --to-sp tsp1q...mh:5000 --to-sp tsp1q...mh:3000
I don't know whether this is considered key reuse. That is why I called your attention to check if it is acceptable.

That's one of the features from silent payments, you can reuse the same silent payment code in the transaction and you're going to get two different output scripts. Have you checked the outputs of the transactions? The one corresponding to the 5000 amount did look similar to the one sending 3000 sats?

tvpeter · 2026-05-11T15:43:30Z

That's one of the features from silent payments, you can reuse the same silent payment code in the transaction and you're going to get two different output scripts.

Alright then, that's fine.

Have you checked the outputs of the transactions? The one corresponding to the 5000 amount did look similar to the one sending 3000 sats?

I did not run it now; I ran it during my last test. I will inspect the output after I test shortly.

tvpeter

tACK c579854

Thank you for adding this feature @nymius.

I have now confirmed that it indeed produced different outputs.

nymius · 2025-09-10T19:39:09Z

Description

This PR adds experimental support for creating silent payment transactions through a new CreateSpTx command. The implementation integrates the bdk_sp crate to enable sending Bitcoin to silent payment addresses.

Key changes:

Adds bdk_sp dependency as an optional feature
Implements CreateSpTx command with support for silent payment recipients
Includes parser for silent payment address:amount pairs
Returns signed transactions ready for broadcast (not PSBTs due to silent payment derivation constraints)

Notes to the reviewers

This feature is marked as EXPERIMENTAL and includes warnings against mainnet use
The command returns signed transactions directly rather than PSBTs because silent payment script pubkey derivation cannot be performed securely in a trustless manner with standard PSBT workflows
RBF is disabled for silent payment transactions (sequence set to MAX)
The implementation handles both single key and extended key signers
Error handling uses temporary .expect() calls that should be addressed in future iterations

Changelog notice

Added: Experimental silent payment transaction creation via CreateSpTx command (feature-gated behind sp flag)

Checklists

All Submissions

I've signed all my commits
I followed the conventional commit guidelines
I ran cargo fmt, clippy and test before committing

New Features

* [ ] I've added tests for the new feature

I've added docs for the new feature

tvpeter

Thank you for working on adding this feature @nymius,

I couldn't test because I don't know how to construct sp recipients. I will check the documentation on the library and will come back to test it. In the meantime, I have left some comments.
Thank you

tvpeter

Thank you for working on this feature @nymius

I left a few comments.

Pls remember to rebase too.

sdmg15

tested ACK.

Script to use to reproduce

export NETWORK=regtest
export EXT_DESCRIPTOR='wpkh(tprv8ZgxMBicQKsPdMzWj9KHvoExKJDqfZFuT5D8o9XVZ3wfyUcnPNPJKncq5df8kpDWnMxoKbGrpS44VawHG17ZSwTkdhEtVRzSYXd14vDYXKw/0/*)'export INT_DESCRIPTOR='wpkh(tprv8ZgxMBicQKsPdMzWj9KHvoExKJDqfZFuT5D8o9XVZ3wfyUcnPNPJKncq5df8kpDWnMxoKbGrpS44VawHG17ZSwTkdhEtVRzSYXd14vDYXKw/1/*)'export DATABASE_TYPE="sqlite"export CLIENT_TYPE="rpc"export SERVER_URL="http://127.0.0.1:18443"export COOKIE="/home/user/.bitcoin/regtest/.cookie"export SP_RECIPIENT="sprt1qqdu4udd7wz7flf89m27teqzp8gxzvgpg3xudw89c0ce0f0pe0gwz6qkc4d7dg587w9rkaa0cj8rf3c28z0g45tgn0t7fzkk4s867w3eugga03ret"
raw_tx=$(cargo run -- wallet create_sp_tx --to-sp $SP_RECIPIENT:1000 | jq -r '.raw_tx'| tr -d '\n')
cargo run --features rpc -- wallet broadcast --tx $raw_tx

sdmg15 · 2026-03-16T11:22:23Z

+ let _resigned = wallet.sign(&mut psbt, SignOptions::default())?;

+ let raw_tx = psbt.extract_tx()?;
+ if cli_opts.pretty {


Here to actually make this "pretty", there's is this shorten function that can be used. I'm not though convinced if that's helpful for users wanting to copy the full raw tx maybe they should just not use the pretty format.

Good point, I'm not sure about the use cases of the pretty flag, but I'm against shortening the transaction.

nymius · 2026-03-18T19:34:03Z

I've addressed the pending comments:

Checked the finalization status of the PSBT after the signing phase before silent payment output derivation.
Implemented logic to handle the drain to silent payment case.

I've also:

Changed the feature flag sp to silent-payments for more clarity.
Squashed all commits into a single one.

codecov · 2026-03-18T19:36:21Z

Codecov Report

❌ Patch coverage is 0.55866% with 178 lines in your changes missing coverage. Please review.
✅ Project coverage is 10.22%. Comparing base (07fd32f) to head (c579854).
⚠️ Report is 7 commits behind head on master.

Files with missing lines	Patch %	Lines
src/handlers.rs	0.61%	162 Missing ⚠️
src/utils.rs	0.00%	16 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## master #220 +/- ##
==========================================
- Coverage 11.13% 10.22% -0.91% 
==========================================
Files 8 8 Lines 2488 2709 +221 ==========================================
Hits 277 277 - Misses 2211 2432 +221

Flag	Coverage Δ
rust	`10.22% <0.55%> (-0.91%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

sdmg15 · 2026-04-22T14:25:13Z

reACK 516af1b

tvpeter

tACK 516af1b

Well done @nymius, I have left a few nits for you.

Also, my final thoughts:
i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?
i) Since createtx and createsptx are almost similar, it would be great to merge createsptx into the existing createtx to improve the UX for users, but allow the fn to detect an SP address and handle it internally. This can be in another PR.

- Adds CreateSpTx command to create transactions with silent payment outputs: this command creates signed transactions directly rather than PSBTs due to current limitations in secure shared derivation. It supports mixed recipients: regular addresses + silent payments. It DOES NOT support RBF for the created transactions. It generates signed transactions ready for broadcasting. - Adds SilentPaymentCode command to create silent payment codes from public keys and network: the silent payment code generated is independent from any of the other stateful features of bdk-cli. This command is mainly intended for experimental use, do not lock any funds to the generated code if you don't know what you are doing and don't have the keys matching the public keys used. - Adds bdk_sp dependency with "silent-payments" feature flag. - Adds silent payment recipient parsing utility. - Add README section for new silent payment commands. Note: This is experimental functionality for testing only, not recommended for mainnet use. Signed-off-by: nymius <155548262+nymius@users.noreply.github.com>

nymius · 2026-05-11T14:02:12Z

Also, my final thoughts: i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?

I'm not sure I follow you here. The current implementation works with multiple SP codes or with a single one repeated multiple times. Do you mean if I have tested explicitly with bdk-cli? I can check it again.

i) Since createtx and createsptx are almost similar, it would be great to merge createsptx into the existing createtx to improve the UX for users, but allow the fn to detect an SP address and handle it internally. This can be in another PR.

The idea of keeping them separated is that is easier to remove this command and replace it by a more mature silent payment sending command later. But we can work the details in another Issue/PR.

tvpeter · 2026-05-11T15:28:13Z

Also, my final thoughts: i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?
I'm not sure I follow you here. The current implementation works with multiple SP codes or with a single one repeated multiple times. Do you mean if I have tested explicitly with bdk-cli? I can check it again.

The latter is what I am referring to; a single user can send more than one output to the same SP code e.g

... create_sp_tx --to-sp tsp1q...mh:5000 --to-sp tsp1q...mh:3000

I don't know whether this is considered key reuse. That is why I called your attention to check if it is acceptable.

nymius · 2026-05-11T15:34:44Z

Also, my final thoughts: i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?
I'm not sure I follow you here. The current implementation works with multiple SP codes or with a single one repeated multiple times. Do you mean if I have tested explicitly with bdk-cli? I can check it again.
The latter is what I am referring to; a single user can send more than one output to the same SP code e.g
... create_sp_tx --to-sp tsp1q...mh:5000 --to-sp tsp1q...mh:3000
I don't know whether this is considered key reuse. That is why I called your attention to check if it is acceptable.

That's one of the features from silent payments, you can reuse the same silent payment code in the transaction and you're going to get two different output scripts. Have you checked the outputs of the transactions? The one corresponding to the 5000 amount did look similar to the one sending 3000 sats?

tvpeter · 2026-05-11T15:43:30Z

That's one of the features from silent payments, you can reuse the same silent payment code in the transaction and you're going to get two different output scripts.

Alright then, that's fine.

Have you checked the outputs of the transactions? The one corresponding to the 5000 amount did look similar to the one sending 3000 sats?

I did not run it now; I ran it during my last test. I will inspect the output after I test shortly.

tvpeter

tACK c579854

Thank you for adding this feature @nymius.

I have now confirmed that it indeed produced different outputs.

nymius · 2025-09-10T19:39:09Z

Description

This PR adds experimental support for creating silent payment transactions through a new CreateSpTx command. The implementation integrates the bdk_sp crate to enable sending Bitcoin to silent payment addresses.

Key changes:

Adds bdk_sp dependency as an optional feature
Implements CreateSpTx command with support for silent payment recipients
Includes parser for silent payment address:amount pairs
Returns signed transactions ready for broadcast (not PSBTs due to silent payment derivation constraints)

Notes to the reviewers

This feature is marked as EXPERIMENTAL and includes warnings against mainnet use
The command returns signed transactions directly rather than PSBTs because silent payment script pubkey derivation cannot be performed securely in a trustless manner with standard PSBT workflows
RBF is disabled for silent payment transactions (sequence set to MAX)
The implementation handles both single key and extended key signers
Error handling uses temporary .expect() calls that should be addressed in future iterations

Changelog notice

Added: Experimental silent payment transaction creation via CreateSpTx command (feature-gated behind sp flag)

Checklists

All Submissions

I've signed all my commits
I followed the conventional commit guidelines
I ran cargo fmt, clippy and test before committing

New Features

* [ ] I've added tests for the new feature

I've added docs for the new feature

tvpeter

Thank you for working on adding this feature @nymius,

I couldn't test because I don't know how to construct sp recipients. I will check the documentation on the library and will come back to test it. In the meantime, I have left some comments.
Thank you

tvpeter

Thank you for working on this feature @nymius

I left a few comments.

Pls remember to rebase too.

sdmg15

tested ACK.

Script to use to reproduce

export NETWORK=regtest
export EXT_DESCRIPTOR='wpkh(tprv8ZgxMBicQKsPdMzWj9KHvoExKJDqfZFuT5D8o9XVZ3wfyUcnPNPJKncq5df8kpDWnMxoKbGrpS44VawHG17ZSwTkdhEtVRzSYXd14vDYXKw/0/*)'export INT_DESCRIPTOR='wpkh(tprv8ZgxMBicQKsPdMzWj9KHvoExKJDqfZFuT5D8o9XVZ3wfyUcnPNPJKncq5df8kpDWnMxoKbGrpS44VawHG17ZSwTkdhEtVRzSYXd14vDYXKw/1/*)'export DATABASE_TYPE="sqlite"export CLIENT_TYPE="rpc"export SERVER_URL="http://127.0.0.1:18443"export COOKIE="/home/user/.bitcoin/regtest/.cookie"export SP_RECIPIENT="sprt1qqdu4udd7wz7flf89m27teqzp8gxzvgpg3xudw89c0ce0f0pe0gwz6qkc4d7dg587w9rkaa0cj8rf3c28z0g45tgn0t7fzkk4s867w3eugga03ret"
raw_tx=$(cargo run -- wallet create_sp_tx --to-sp $SP_RECIPIENT:1000 | jq -r '.raw_tx'| tr -d '\n')
cargo run --features rpc -- wallet broadcast --tx $raw_tx

sdmg15 · 2026-03-16T11:22:23Z

+ let _resigned = wallet.sign(&mut psbt, SignOptions::default())?;

+ let raw_tx = psbt.extract_tx()?;
+ if cli_opts.pretty {


Here to actually make this "pretty", there's is this shorten function that can be used. I'm not though convinced if that's helpful for users wanting to copy the full raw tx maybe they should just not use the pretty format.

Good point, I'm not sure about the use cases of the pretty flag, but I'm against shortening the transaction.

nymius · 2026-03-18T19:34:03Z

I've addressed the pending comments:

Checked the finalization status of the PSBT after the signing phase before silent payment output derivation.
Implemented logic to handle the drain to silent payment case.

I've also:

Changed the feature flag sp to silent-payments for more clarity.
Squashed all commits into a single one.

codecov · 2026-03-18T19:36:21Z

Codecov Report

❌ Patch coverage is 0.55866% with 178 lines in your changes missing coverage. Please review.
✅ Project coverage is 10.22%. Comparing base (07fd32f) to head (c579854).
⚠️ Report is 7 commits behind head on master.

Files with missing lines	Patch %	Lines
src/handlers.rs	0.61%	162 Missing ⚠️
src/utils.rs	0.00%	16 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## master #220 +/- ##
==========================================
- Coverage 11.13% 10.22% -0.91% 
==========================================
Files 8 8 Lines 2488 2709 +221 ==========================================
Hits 277 277 - Misses 2211 2432 +221

Flag	Coverage Δ
rust	`10.22% <0.55%> (-0.91%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

sdmg15 · 2026-04-22T14:25:13Z

reACK 516af1b

tvpeter

tACK 516af1b

Well done @nymius, I have left a few nits for you.

Also, my final thoughts:
i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?
i) Since createtx and createsptx are almost similar, it would be great to merge createsptx into the existing createtx to improve the UX for users, but allow the fn to detect an SP address and handle it internally. This can be in another PR.

- Adds CreateSpTx command to create transactions with silent payment outputs: this command creates signed transactions directly rather than PSBTs due to current limitations in secure shared derivation. It supports mixed recipients: regular addresses + silent payments. It DOES NOT support RBF for the created transactions. It generates signed transactions ready for broadcasting. - Adds SilentPaymentCode command to create silent payment codes from public keys and network: the silent payment code generated is independent from any of the other stateful features of bdk-cli. This command is mainly intended for experimental use, do not lock any funds to the generated code if you don't know what you are doing and don't have the keys matching the public keys used. - Adds bdk_sp dependency with "silent-payments" feature flag. - Adds silent payment recipient parsing utility. - Add README section for new silent payment commands. Note: This is experimental functionality for testing only, not recommended for mainnet use. Signed-off-by: nymius <155548262+nymius@users.noreply.github.com>

nymius · 2026-05-11T14:02:12Z

Also, my final thoughts: i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?

I'm not sure I follow you here. The current implementation works with multiple SP codes or with a single one repeated multiple times. Do you mean if I have tested explicitly with bdk-cli? I can check it again.

i) Since createtx and createsptx are almost similar, it would be great to merge createsptx into the existing createtx to improve the UX for users, but allow the fn to detect an SP address and handle it internally. This can be in another PR.

The idea of keeping them separated is that is easier to remove this command and replace it by a more mature silent payment sending command later. But we can work the details in another Issue/PR.

tvpeter · 2026-05-11T15:28:13Z

Also, my final thoughts: i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?
I'm not sure I follow you here. The current implementation works with multiple SP codes or with a single one repeated multiple times. Do you mean if I have tested explicitly with bdk-cli? I can check it again.

The latter is what I am referring to; a single user can send more than one output to the same SP code e.g

... create_sp_tx --to-sp tsp1q...mh:5000 --to-sp tsp1q...mh:3000

I don't know whether this is considered key reuse. That is why I called your attention to check if it is acceptable.

nymius · 2026-05-11T15:34:44Z

Also, my final thoughts: i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?
I'm not sure I follow you here. The current implementation works with multiple SP codes or with a single one repeated multiple times. Do you mean if I have tested explicitly with bdk-cli? I can check it again.
The latter is what I am referring to; a single user can send more than one output to the same SP code e.g
... create_sp_tx --to-sp tsp1q...mh:5000 --to-sp tsp1q...mh:3000
I don't know whether this is considered key reuse. That is why I called your attention to check if it is acceptable.

That's one of the features from silent payments, you can reuse the same silent payment code in the transaction and you're going to get two different output scripts. Have you checked the outputs of the transactions? The one corresponding to the 5000 amount did look similar to the one sending 3000 sats?

tvpeter · 2026-05-11T15:43:30Z

That's one of the features from silent payments, you can reuse the same silent payment code in the transaction and you're going to get two different output scripts.

Alright then, that's fine.

Have you checked the outputs of the transactions? The one corresponding to the 5000 amount did look similar to the one sending 3000 sats?

I did not run it now; I ran it during my last test. I will inspect the output after I test shortly.

tvpeter

tACK c579854

Thank you for adding this feature @nymius.

I have now confirmed that it indeed produced different outputs.

nymius · 2025-09-10T19:39:09Z

Description

This PR adds experimental support for creating silent payment transactions through a new CreateSpTx command. The implementation integrates the bdk_sp crate to enable sending Bitcoin to silent payment addresses.

Key changes:

Adds bdk_sp dependency as an optional feature
Implements CreateSpTx command with support for silent payment recipients
Includes parser for silent payment address:amount pairs
Returns signed transactions ready for broadcast (not PSBTs due to silent payment derivation constraints)

Notes to the reviewers

This feature is marked as EXPERIMENTAL and includes warnings against mainnet use
The command returns signed transactions directly rather than PSBTs because silent payment script pubkey derivation cannot be performed securely in a trustless manner with standard PSBT workflows
RBF is disabled for silent payment transactions (sequence set to MAX)
The implementation handles both single key and extended key signers
Error handling uses temporary .expect() calls that should be addressed in future iterations

Changelog notice

Added: Experimental silent payment transaction creation via CreateSpTx command (feature-gated behind sp flag)

Checklists

All Submissions

I've signed all my commits
I followed the conventional commit guidelines
I ran cargo fmt, clippy and test before committing

New Features

* [ ] I've added tests for the new feature

I've added docs for the new feature

tvpeter

Thank you for working on adding this feature @nymius,

I couldn't test because I don't know how to construct sp recipients. I will check the documentation on the library and will come back to test it. In the meantime, I have left some comments.
Thank you

tvpeter

Thank you for working on this feature @nymius

I left a few comments.

Pls remember to rebase too.

sdmg15

tested ACK.

Script to use to reproduce

export NETWORK=regtest
export EXT_DESCRIPTOR='wpkh(tprv8ZgxMBicQKsPdMzWj9KHvoExKJDqfZFuT5D8o9XVZ3wfyUcnPNPJKncq5df8kpDWnMxoKbGrpS44VawHG17ZSwTkdhEtVRzSYXd14vDYXKw/0/*)'export INT_DESCRIPTOR='wpkh(tprv8ZgxMBicQKsPdMzWj9KHvoExKJDqfZFuT5D8o9XVZ3wfyUcnPNPJKncq5df8kpDWnMxoKbGrpS44VawHG17ZSwTkdhEtVRzSYXd14vDYXKw/1/*)'export DATABASE_TYPE="sqlite"export CLIENT_TYPE="rpc"export SERVER_URL="http://127.0.0.1:18443"export COOKIE="/home/user/.bitcoin/regtest/.cookie"export SP_RECIPIENT="sprt1qqdu4udd7wz7flf89m27teqzp8gxzvgpg3xudw89c0ce0f0pe0gwz6qkc4d7dg587w9rkaa0cj8rf3c28z0g45tgn0t7fzkk4s867w3eugga03ret"
raw_tx=$(cargo run -- wallet create_sp_tx --to-sp $SP_RECIPIENT:1000 | jq -r '.raw_tx'| tr -d '\n')
cargo run --features rpc -- wallet broadcast --tx $raw_tx

sdmg15 · 2026-03-16T11:22:23Z

+ let _resigned = wallet.sign(&mut psbt, SignOptions::default())?;

+ let raw_tx = psbt.extract_tx()?;
+ if cli_opts.pretty {


Here to actually make this "pretty", there's is this shorten function that can be used. I'm not though convinced if that's helpful for users wanting to copy the full raw tx maybe they should just not use the pretty format.

Good point, I'm not sure about the use cases of the pretty flag, but I'm against shortening the transaction.

nymius · 2026-03-18T19:34:03Z

I've addressed the pending comments:

Checked the finalization status of the PSBT after the signing phase before silent payment output derivation.
Implemented logic to handle the drain to silent payment case.

I've also:

Changed the feature flag sp to silent-payments for more clarity.
Squashed all commits into a single one.

codecov · 2026-03-18T19:36:21Z

Codecov Report

❌ Patch coverage is 0.55866% with 178 lines in your changes missing coverage. Please review.
✅ Project coverage is 10.22%. Comparing base (07fd32f) to head (c579854).
⚠️ Report is 7 commits behind head on master.

Files with missing lines	Patch %	Lines
src/handlers.rs	0.61%	162 Missing ⚠️
src/utils.rs	0.00%	16 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## master #220 +/- ##
==========================================
- Coverage 11.13% 10.22% -0.91% 
==========================================
Files 8 8 Lines 2488 2709 +221 ==========================================
Hits 277 277 - Misses 2211 2432 +221

Flag	Coverage Δ
rust	`10.22% <0.55%> (-0.91%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

sdmg15 · 2026-04-22T14:25:13Z

reACK 516af1b

tvpeter

tACK 516af1b

Well done @nymius, I have left a few nits for you.

Also, my final thoughts:
i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?
i) Since createtx and createsptx are almost similar, it would be great to merge createsptx into the existing createtx to improve the UX for users, but allow the fn to detect an SP address and handle it internally. This can be in another PR.

- Adds CreateSpTx command to create transactions with silent payment outputs: this command creates signed transactions directly rather than PSBTs due to current limitations in secure shared derivation. It supports mixed recipients: regular addresses + silent payments. It DOES NOT support RBF for the created transactions. It generates signed transactions ready for broadcasting. - Adds SilentPaymentCode command to create silent payment codes from public keys and network: the silent payment code generated is independent from any of the other stateful features of bdk-cli. This command is mainly intended for experimental use, do not lock any funds to the generated code if you don't know what you are doing and don't have the keys matching the public keys used. - Adds bdk_sp dependency with "silent-payments" feature flag. - Adds silent payment recipient parsing utility. - Add README section for new silent payment commands. Note: This is experimental functionality for testing only, not recommended for mainnet use. Signed-off-by: nymius <155548262+nymius@users.noreply.github.com>

nymius · 2026-05-11T14:02:12Z

Also, my final thoughts: i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?

I'm not sure I follow you here. The current implementation works with multiple SP codes or with a single one repeated multiple times. Do you mean if I have tested explicitly with bdk-cli? I can check it again.

i) Since createtx and createsptx are almost similar, it would be great to merge createsptx into the existing createtx to improve the UX for users, but allow the fn to detect an SP address and handle it internally. This can be in another PR.

The idea of keeping them separated is that is easier to remove this command and replace it by a more mature silent payment sending command later. But we can work the details in another Issue/PR.

tvpeter · 2026-05-11T15:28:13Z

Also, my final thoughts: i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?
I'm not sure I follow you here. The current implementation works with multiple SP codes or with a single one repeated multiple times. Do you mean if I have tested explicitly with bdk-cli? I can check it again.

The latter is what I am referring to; a single user can send more than one output to the same SP code e.g

... create_sp_tx --to-sp tsp1q...mh:5000 --to-sp tsp1q...mh:3000

I don't know whether this is considered key reuse. That is why I called your attention to check if it is acceptable.

nymius · 2026-05-11T15:34:44Z

Also, my final thoughts: i) With the current implementation, it is possible to send multiple outputs to the same SP code in the same tx. Can you consider checking for this?
I'm not sure I follow you here. The current implementation works with multiple SP codes or with a single one repeated multiple times. Do you mean if I have tested explicitly with bdk-cli? I can check it again.
The latter is what I am referring to; a single user can send more than one output to the same SP code e.g
... create_sp_tx --to-sp tsp1q...mh:5000 --to-sp tsp1q...mh:3000
I don't know whether this is considered key reuse. That is why I called your attention to check if it is acceptable.

That's one of the features from silent payments, you can reuse the same silent payment code in the transaction and you're going to get two different output scripts. Have you checked the outputs of the transactions? The one corresponding to the 5000 amount did look similar to the one sending 3000 sats?

tvpeter · 2026-05-11T15:43:30Z

That's one of the features from silent payments, you can reuse the same silent payment code in the transaction and you're going to get two different output scripts.

Alright then, that's fine.

Have you checked the outputs of the transactions? The one corresponding to the 5000 amount did look similar to the one sending 3000 sats?

I did not run it now; I ran it during my last test. I will inspect the output after I test shortly.

tvpeter

tACK c579854

Thank you for adding this feature @nymius.

I have now confirmed that it indeed produced different outputs.

github-project-automationBot added this to BDK-CLI Sep 10, 2025

nymius requested review from notmandatory and tvpeter and removed request for notmandatory September 10, 2025 19:39

nymius force-pushed the feat/sp-psbt-send branch from e0a13af to bc40b76Compare September 11, 2025 12:09

tvpeter requested changes Oct 11, 2025
View reviewed changes

Comment threadsrc/handlers.rs Outdated
Comment threadsrc/utils.rs Outdated
Comment threadsrc/commands.rs
Comment threadsrc/commands.rs

nymius force-pushed the feat/sp-psbt-send branch from bc40b76 to 8d15df7Compare November 4, 2025 14:12

nymius requested a review from tvpeter November 4, 2025 14:12

tvpeter reviewed Feb 4, 2026
View reviewed changes

Comment threadsrc/error.rs
Comment threadsrc/handlers.rs Outdated
Comment threadsrc/handlers.rs

tvpeter assigned nymius Feb 23, 2026

tvpeter moved this to In Progress in BDK-CLI Feb 23, 2026

sdmg15 reviewed Mar 16, 2026
View reviewed changes

nymius force-pushed the feat/sp-psbt-send branch from 8d15df7 to 8290461Compare March 18, 2026 19:22

nymius force-pushed the feat/sp-psbt-send branch 2 times, most recently from d297c8e to beaca7eCompare March 19, 2026 22:25

notmandatory moved this from In Progress to Ready to Review in BDK-CLI Mar 24, 2026

nymius force-pushed the feat/sp-psbt-send branch from beaca7e to 516af1bCompare April 13, 2026 13:07

tvpeter reviewed Apr 23, 2026
View reviewed changes

Comment threadsrc/commands.rs Outdated

tvpeter reviewed Apr 23, 2026
View reviewed changes

Comment threadsrc/commands.rs Outdated

tvpeter reviewed Apr 23, 2026
View reviewed changes

tvpeter added this to the CLI 4.0.0 milestone May 6, 2026

tvpeter moved this from Ready to Review to In Progress in BDK-CLI May 6, 2026

nymius force-pushed the feat/sp-psbt-send branch from 516af1b to c579854Compare May 11, 2026 13:58

tvpeter approved these changes May 14, 2026
View reviewed changes

This comment was marked as duplicate.
Sign in to view

tvpeter merged commit 4a8e3ce into bitcoindevkit:masterMay 19, 2026
7 of 9 checks passed

github-project-automationBot moved this from In Progress to Done in BDK-CLI May 19, 2026

vadim-anfv mentioned this pull request May 27, 2026
feat(compile): compile taproot descriptor with randomized unspendable internal key #225
Merged
6 tasks

tvpeter mentioned this pull request Jul 20, 2026
Release 4.0.0 #304
Closed
14 tasks