-
Notifications
You must be signed in to change notification settings - Fork 83
Add experimental silent payment transaction creation support #220
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
88e02dd
6d2b508
157250a
38abbdd
795e707
e8f2e48
4154a33
d0873d1
84f8750
8d15df7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -14,6 +14,9 @@ | |
|
|
||
| #![allow(clippy::large_enum_variant)] | ||
|
|
||
| #[cfg(feature = "sp")] | ||
| use {crate::utils::parse_sp_code_value_pairs, bdk_sp::encoding::SilentPaymentCode}; | ||
|
|
||
| use bdk_wallet::bitcoin::{ | ||
| Address, Network, OutPoint, ScriptBuf, | ||
| bip32::{DerivationPath, Xpriv}, | ||
|
|
@@ -107,6 +110,19 @@ pub enum CliSubCommand { | |
| #[command(flatten)] | ||
| wallet_opts: WalletOpts, | ||
| }, | ||
| /// Silent payment code generation tool. | ||
| /// | ||
| /// Allows the encoding of two public keys into a silent payment code. | ||
| /// Useful to create silent payment transactions using fake silent payment codes. | ||
| #[cfg(feature = "sp")] | ||
| SilentPaymentCode { | ||
| /// The scan public key to use on the silent payment code. | ||
| #[arg(long = "scan_public_key")] | ||
| scan: bdk_sp::bitcoin::secp256k1::PublicKey, | ||
| /// The spend public key to use on the silent payment code. | ||
| #[arg(long = "spend_public_key")] | ||
| spend: bdk_sp::bitcoin::secp256k1::PublicKey, | ||
| } | ||
| } | ||
|
|
||
| /// Wallet operation subcommands. | ||
|
|
@@ -311,6 +327,62 @@ pub enum OfflineWalletSubCommand { | |
| )] | ||
| add_data: Option<String>, //base 64 econding | ||
| }, | ||
| /// Creates a silent payment transaction | ||
| /// | ||
| /// This sub-command is **EXPERIMENTAL** and should only be used for testing. Do not use this | ||
| /// feature to create transactions that spend actual funds on the Bitcoin mainnet. | ||
|
|
||
| // This command DOES NOT return a PSBT. Instead, it directly returns a signed transaction | ||
| // ready for broadcast, as it is not yet possible to perform a shared derivation of a silent | ||
| // payment script pubkey in a secure and trustless manner. | ||
| #[cfg(feature = "sp")] | ||
| CreateSpTx { | ||
| /// Adds a recipient to the transaction. | ||
| // Clap Doesn't support complex vector parsing https://github.com/clap-rs/clap/issues/1704. | ||
| // Address and amount parsing is done at run time in handler function. | ||
| #[arg(env = "ADDRESS:SAT", long = "to", required = false, value_parser = parse_recipient)] | ||
| recipients: Option<Vec<(ScriptBuf, u64)>>, | ||
| /// Parse silent payment recipients | ||
| #[arg(long = "to-sp", required = true, value_parser = parse_sp_code_value_pairs)] | ||
| silent_payment_recipients: Vec<(SilentPaymentCode, u64)>, | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. how can one construct sp_recipients? can you add that to the readme?
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Each silent payment recipient is a string of the form
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What I think is that, if it is possible, you should add deriving SP addresses to this PR. I wanted to test how you implemented it in the CLI v2 but it broke. Else you can add a link to the test addresses so it is easy for users to find them.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. But if we add the chances to derive addresses, then we are allowing the creation of transactions locking funds into those addresses. I could restrict this functionality to only derive testnet addresses, so no one lose any real funds.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, only testnet addresses are fine. We generally warn users against using this tool for mainnet. |
||
| /// Sends all the funds (or all the selected utxos). Requires only one recipient with value 0. | ||
| #[arg(long = "send_all", short = 'a')] | ||
| send_all: bool, | ||
| /// Make a PSBT that can be signed by offline signers and hardware wallets. Forces the addition of `non_witness_utxo` and more details to let the signer identify the change output. | ||
| #[arg(long = "offline_signer")] | ||
| offline_signer: bool, | ||
| /// Selects which utxos *must* be spent. | ||
| #[arg(env = "MUST_SPEND_TXID:VOUT", long = "utxos", value_parser = parse_outpoint)] | ||
| utxos: Option<Vec<OutPoint>>, | ||
| /// Marks a utxo as unspendable. | ||
| #[arg(env = "CANT_SPEND_TXID:VOUT", long = "unspendable", value_parser = parse_outpoint)] | ||
| unspendable: Option<Vec<OutPoint>>, | ||
| /// Fee rate to use in sat/vbyte. | ||
| #[arg(env = "SATS_VBYTE", short = 'f', long = "fee_rate")] | ||
| fee_rate: Option<f32>, | ||
| /// Selects which policy should be used to satisfy the external descriptor. | ||
| #[arg(env = "EXT_POLICY", long = "external_policy")] | ||
| external_policy: Option<String>, | ||
| /// Selects which policy should be used to satisfy the internal descriptor. | ||
| #[arg(env = "INT_POLICY", long = "internal_policy")] | ||
| internal_policy: Option<String>, | ||
| /// Optionally create an OP_RETURN output containing given String in utf8 encoding (max 80 bytes) | ||
| #[arg( | ||
| env = "ADD_STRING", | ||
| long = "add_string", | ||
| short = 's', | ||
| conflicts_with = "add_data" | ||
| )] | ||
| add_string: Option<String>, | ||
| /// Optionally create an OP_RETURN output containing given base64 encoded String. (max 80 bytes) | ||
| #[arg( | ||
| env = "ADD_DATA", | ||
| long = "add_data", | ||
| short = 'o', | ||
| conflicts_with = "add_string" | ||
| )] | ||
| add_data: Option<String>, //base 64 econding | ||
| }, | ||
| /// Bumps the fees of an RBF transaction. | ||
| BumpFee { | ||
| /// TXID of the transaction to update. | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there a need to add these recipients again since the focus is on sp_recipients?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want to show that's still possible to send a non silent payment output together with a silent payment output in the same transaction, that's why I left this here.