-
Notifications
You must be signed in to change notification settings - Fork 76
feat: expose Wallet::get_psbt_input
#1032
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
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,8 +1,9 @@ | ||
| use crate::bitcoin::{Amount, FeeRate, OutPoint, Psbt, Script, Transaction, TxOut, Txid}; | ||
| use crate::bitcoin::{Amount, FeeRate, Input, OutPoint, Psbt, Script, Transaction, TxOut, Txid}; | ||
| use crate::descriptor::Descriptor; | ||
| use crate::error::{ | ||
| CalculateFeeError, CannotConnectError, CreateWithPersistError, DescriptorError, | ||
| LoadWithPersistError, PersistenceError, SignerError, TxidParseError, | ||
| GetPsbtInputError, LoadWithPersistError, PersistenceError, SighashParseError, SignerError, | ||
| TxidParseError, | ||
| }; | ||
| use crate::store::{PersistenceType, Persister}; | ||
| use crate::types::{ | ||
|
|
@@ -11,13 +12,15 @@ use crate::types::{ | |
| SyncRequestBuilder, UnconfirmedTx, Update, WalletEvent, WalletKeychain, | ||
| }; | ||
|
|
||
| use bdk_wallet::bitcoin::psbt::PsbtSighashType as BdkPsbtSighashType; | ||
| use bdk_wallet::bitcoin::Network; | ||
| use bdk_wallet::keys::KeyMap; | ||
| #[allow(deprecated)] | ||
| use bdk_wallet::signer::SignOptions as BdkSignOptions; | ||
| use bdk_wallet::{PersistedWallet, Wallet as BdkWallet}; | ||
|
|
||
| use std::ops::DerefMut; | ||
| use std::str::FromStr; | ||
| use std::sync::{Arc, Mutex, MutexGuard}; | ||
|
|
||
| /// A Bitcoin wallet. | ||
|
|
@@ -214,6 +217,26 @@ impl Wallet { | |
| .map(|local_output| local_output.into()) | ||
| } | ||
|
|
||
| /// Get the corresponding PSBT Input for a `LocalOutput`. | ||
| #[uniffi::method(default(sighash_type = None, only_witness_utxo = false))] | ||
| pub fn get_psbt_input( | ||
| &self, | ||
| utxo: LocalOutput, | ||
| sighash_type: Option<String>, | ||
| only_witness_utxo: bool, | ||
| ) -> Result<Input, GetPsbtInputError> { | ||
|
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. Nice! Took me a while to see why we are returning GetPsbtInputError here when we have CreateTxError. This is good as we need to handle for string parsing, the 2 possible errors from bdk-wallet (miniscript and unknown), and all others.
Collaborator
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. Thanks, yup exactly |
||
| let outpoint = utxo.outpoint.clone(); | ||
| let sighash_type = sighash_type | ||
| .map(|sighash_type| parse_sighash_type(&sighash_type)) | ||
| .transpose()?; | ||
| let psbt_input = self | ||
| .get_wallet() | ||
| .get_psbt_input(utxo.into(), sighash_type, only_witness_utxo) | ||
| .map_err(|error| GetPsbtInputError::from_bdk_create_tx_error(error, outpoint))?; | ||
|
|
||
| Ok(Input::from(&psbt_input)) | ||
| } | ||
|
|
||
| /// Attempt to reveal the next address of the given `keychain`. | ||
| /// | ||
| /// This will increment the keychain's derivation index. If the keychain's descriptor doesn't | ||
|
|
@@ -744,3 +767,9 @@ impl Wallet { | |
| self.inner_mutex.lock().expect("wallet") | ||
| } | ||
| } | ||
|
|
||
| fn parse_sighash_type(sighash: &str) -> Result<BdkPsbtSighashType, SighashParseError> { | ||
| BdkPsbtSighashType::from_str(sighash).map_err(|error| SighashParseError::Invalid { | ||
| error_message: error.to_string(), | ||
| }) | ||
| } | ||
Uh oh!
There was an error while loading. Please reload this page.
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 see we leave out first_seen in our ChainPosition type definition but now we have to use same timestamp when passing back.
Maybe not related to this PR; Asking in general... Do we really not need first seen?
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.
Good question, cuz we had already exposed first_seen on TxGraphChangeSet, but ChainPosition was still using the older single timestamp field which maps to upstream last_seen. I opened a followup PR to expose both first_seen and last_seen there too: #1039