-
Notifications
You must be signed in to change notification settings - Fork 46
Implement create_psbt for Wallet
#297
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?
Conversation
673d602 to
77e1d20
Compare
Pull Request Test Coverage Report for Build 19016316365Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
|
I like the What do you envision the API for replace-by-fee transactions look like in this new bdk-tx world? I'm picturing something like |
2c54be1 to
6f525d1
Compare
6f525d1 to
4493cbd
Compare
create_psbt for Walletcreate_psbt for Wallet
thunderbiscuit
left a comment
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.
So this is more of a conceptual review/question set, as I'm getting acquainted with the PR, and it also requires knowledge and understanding of the bdk-tx crate/workflow.
One general question I have is do you think is missing in functionality between this and the current TxBuilder? Can we make a todo list that compares functionality with the current TxBuilder to better visualize how close of a replacement this is, or if it only provides part of the functionality for now (and if so which parts)?
I haven't had time to look/test the examples and my day is over, but I'll come back to this on Monday.
| /// | ||
| /// A single outpoint may appear at most once in the list of UTXOs to spend. The caller is | ||
| /// responsible for ensuring that elements of `outpoints` correspond to outputs of previous | ||
| /// transactions and are currently unspent. |
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.
Where is the error thrown if this requirement is not met? It's a good place to let people know and I would add it to the docs here.
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.
Wallet::create_psbt will throw a CreatePsbtError::UnknownUtxo if the outpoint doesn't match a previously indexed outpoint (i.e. a wallet-owned tx output). I agree it should be documented somewhere.
| } | ||
|
|
||
| /// Set the definite descriptor used for generating the change output. | ||
| pub fn change_descriptor(&mut self, desc: DefiniteDescriptor) -> &mut Self { |
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 it correct to think that if not defined here, the change just goes to:
- The next index on Keychain::Internal if available
- If no internal keychain is available, the next index on the KeychainKind::External
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.
Ok awesome thanks for confirming. In this case, I'd just mention this in the docs (that this method is basically "if you want to send change elsewhere than your default change location").
| /// `ReplaceParams` provides a thin wrapper around [`PsbtParams`] and is intended for | ||
| /// crafting Replace-By-Fee transactions (RBF). | ||
| #[derive(Debug, Default)] | ||
| pub struct ReplaceParams { |
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.
Can you tell me more about why we want this new ReplaceParams type? Naively I would have thought you'd just call PsbtParams::replace and you'd get a sort of pre-populated PsbtParams ready for replacing your tx, but I assume this doesn't quite work?
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.
Naively I would have thought you'd just call
PsbtParams::replaceand you'd get a sort of pre-populated PsbtParams ready for replacing your tx
That works too.
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.
If that works that's my preferred approach, unless there is something I'm not seeing.
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.
Sorry I didn't elaborate before. We want to provide some separation to make it difficult to misuse the API. Once you've committed to replacing a tx, you can't go back and fiddle with the params, instead you're limited to doing only what is permitted by the ReplaceParams, at least that's the general idea. This prevents a situation where some params override others and the implementation becomes unwieldy.
Right now the key difference is that you're not allowed to add more utxos (outpoints) in addition the ones being replaced, because it may lead to creating an invalid tx. Still open to suggestions for improvement.
| /// # Ok::<_, anyhow::Error>(()) | ||
| /// ``` | ||
| #[cfg(feature = "std")] | ||
| pub fn create_psbt(&self, params: PsbtParams) -> Result<(Psbt, Finalizer), CreatePsbtError> { |
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.
Why do we return this Finalizer? I'd like to see that expanded upon in the docs. When looking into it I see that the Finalizer is
pub struct Finalizer {
pub(crate) plans: HashMap<OutPoint, Plan>,
}so probably something that helps the signers figure out what to sign and how to sign once you give them a psbt, but I'm not sure. The docs on Finalizer are also a bit... brief 😂😂
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 still need to take a deeper look into bdk-tx, but I think the name could be misleading with Input Finalizer from the PSBT BIP-174 (if it's not following the same proposed idea).
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.
It is meant to handle the role of a PSBT input finalizer as described in BIP174.
oleonardolima
left a comment
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 did an initial review, with simple comments/questions. Still need to take a deeper look into bdk-tx and do a more thorough review here.
| /// No Bnb solution. | ||
| Bnb(bdk_coin_select::NoBnbSolution), | ||
| /// Non-sufficient funds | ||
| InsufficientFunds(bdk_coin_select::InsufficientFunds), |
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.
Can't we have a generic CS error instead ?
| /// # Ok::<_, anyhow::Error>(()) | ||
| /// ``` | ||
| #[cfg(feature = "std")] | ||
| pub fn create_psbt(&self, params: PsbtParams) -> Result<(Psbt, Finalizer), CreatePsbtError> { |
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 still need to take a deeper look into bdk-tx, but I think the name could be misleading with Input Finalizer from the PSBT BIP-174 (if it's not following the same proposed idea).
|
Thank you for the quick review @thunderbiscuit @oleonardolima. |
TxBuilder vs PsbtParams feature comparisonsubject to change
N/A: |
4493cbd to
a7afecb
Compare
|
3d7bd2e to
5285937
Compare
I think a straightforward approach is to set a target feerate of I can see it being relevant to CPFP, since there we're less concerned about the feerate of an individual tx and more so with the fee needed to bump a package to a target feerate. |
`TxOrdering` is made generic by exposing the generic from `TxSort` function. The benefit is that we're no longer limited to ordering lists of only `TxIn` or `TxOut`. We use bitcoin `TxIn` and `TxOut` as the default type parameter to maintain backward compatibility. Add `sort_with_rng` for `TxOrdering<In, Out>` for sorting two generic mutable slices. This will be useful in a later commit by applying a `TxOrdering` to the Input/Output sets of a `Selection`.
We add the `psbt::params` module along with new types including `PsbtParams`, `ReplaceParams`, and `SelectionStrategy`. `PsbtParams` is mostly inspired by `TxParams` from `tx_builder.rs`, except that we've removed support for `policy_path` in favor of `add_assets` API. Further enhancements include `.utxo_filter` and `.canonical_params` member fields. In `lib.rs` re-export everything under `psbt` module. - deps: Add `bdk_tx` 0.1.0 - deps: Add `bdk_coin_select` 0.4.1
596565f to
d562584
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #297 +/- ##
==========================================
- Coverage 84.81% 84.77% -0.04%
==========================================
Files 23 24 +1
Lines 8145 8889 +744
==========================================
+ Hits 6908 7536 +628
- Misses 1237 1353 +116
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
We use the new `PsbtParams` to add methods on `Wallet` for creating PSBTs, including RBF transactions. `Wallet::create_psbt` and `Wallet::replace_by_fee` each have no-std counterparts that take an additional `impl RngCore` parameter. Also adds a high level convenience method `Wallet::replace_by_fee_and_recipients` that exposes the minimum information needed to create an RBF. This commit re-introduces the `Wallet::insert_tx` API for adding transaction data to the wallet that may or may not be canonical from the point of view of the TxGraph. Added `Wallet::transactions_with_params` that allows customizing the internal canonicalization logic. Added new errors to `wallet::errors` - `CreatePsbtError` - `ReplaceByFeeError`
Adds several tests to exercise create-psbt logic and user flow. - test-utils: Add `insert_tx_anchor` test helper for adding a transaction to the wallet with associated anchor block. - deps: Bump `bitcoin` to 0.32.7 in order to make use of `ScriptBuf::new_p2a`.
- `examples/psbt.rs` - `examples/rbf.rs`
d562584 to
f00d309
Compare
Description
Use the new
bdk_txtransaction building library to create PSBTs in BDK Wallet. Primary benefits include the use ofbdk_coin_selectas well asminiscript::planmodule under the hood.fix #164
fix #204
Notes to the reviewers
Remaining TODOs are listed in the table below #297 (comment).
It may help to look over the high level design and rationale which is available here.
Changelog notice
Checklists
All Submissions:
New Features:
Bugfixes:
This pull request breaks the existing API