Skip to content

Introduce canonicalization parameters #1808

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

Merged

Conversation

evanlinjin
Copy link
Member

@evanlinjin evanlinjin commented Jan 23, 2025

Partially Fixes bitcoindevkit/bdk_wallet#40

Description

Add the ability to modify the canonicalization algorithm. Right now, the only modifier is assume_canonical which takes in a Vec (ordered list) of txids and superimposes it on the canonicalization algorithm. Txs later in the list (higher index) have a higher priority (in case of conflicts).

Notes to the reviewers

None at the moment.

Changelog notice

  • Added CanonicalizationParams to allow the caller to modify the canonicalization algorithm. This in a new parameter on CanonicalIter::new.
  • Changed TxGraph::insert_tx to allow for updating a transaction's witness field. This is useful for initially introducing an unsigned tx and adding witnesses later on.

Checklists

All Submissions:

  • I've signed all my commits
  • I followed the contribution guidelines
  • I ran cargo fmt and cargo clippy before committing

New Features:

  • I've added tests for the new feature
  • I've added docs for the new feature

Bugfixes:

  • This pull request breaks the existing API
  • I've added tests to reproduce the issue which are now passing
  • I'm linking the issue being fixed by this PR

@evanlinjin evanlinjin self-assigned this Jan 23, 2025
@evanlinjin evanlinjin added the api A breaking API change label Jan 23, 2025
@evanlinjin evanlinjin added this to the 1.1.0 milestone Jan 23, 2025
@evanlinjin evanlinjin force-pushed the superimposed_canonicalization branch from 4169060 to 0f00cdb Compare January 23, 2025 10:31
@notmandatory
Copy link
Member

Would it make sense to add CanonicalizationMods as a field of TxGraph ?

This way the existing TxGraph method signatures don't change, you'd just need a new function to add TxIds to the CanonicalizationMods in the TxGraph.

And if you could only add new TxIds to your CanonicalizationMods this should still be monotone right?

Then you could also add the CanonicalizationMods data to the tx_graph::Changeset so it's persisted. Of course you'd need to update the persistence crates but wouldn't users need/want to persist these mods anyway so a reloaded wallet shows the same balance and utxos?

For Wallet I'm imaging some higher level functions for the things a wallet user needs. For instance (based on suggestions in bitcoindevkit/bdk_wallet#40):

  1. change TxBuilder::finish to insert new unbroadcast tx and add a canonical mod so their inputs won't be double spent
  2. add a canonical mod for a new RBF tx so it has precedence over the unconfirmed tx it's replacing
  3. list unbroadcast tx (found in CanonicalizationMods but not seen)
  4. add an option to TxBuilder to include inputs from unbroadcast tx(s), the new tx has higher canonicalization
  5. remove tx from CanonicalizationMods after seen in mempool (or would this make TxGraph not monotone?)

@LLFourn
Copy link
Contributor

LLFourn commented Jan 28, 2025

ConceptACK. Would be nice to have draft PR built on this that resolves bitcoindevkit/bdk_wallet#40 so we know that this is all that's needed at the chain level before merging this.

Copy link
Contributor

@oleonardolima oleonardolima left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cACK 0f00cdb

@notmandatory notmandatory removed this from the 1.1.0 milestone Feb 4, 2025
@notmandatory
Copy link
Member

Took this out of the bdk_wallet 1.1 milestone since tagging the release tomorrow.

@evanlinjin
Copy link
Member Author

Would it make sense to add CanonicalizationMods as a field of TxGraph ?

@notmandatory I do not think so. Different calls to canonicalize will be for different purposes. Especially when we add more fields to CanonicalizationMods (i.e. in #1809).

@evanlinjin
Copy link
Member Author

evanlinjin commented Feb 6, 2025

And if you could only add new TxIds to your CanonicalizationMods this should still be monotone right?

We want ordering for these txids. In case of conflict between them, we need a way to prioritize ones over others. This order should be controlled by the caller.

@evanlinjin evanlinjin force-pushed the superimposed_canonicalization branch from c70b40b to b780142 Compare February 28, 2025 06:21
@evanlinjin evanlinjin force-pushed the superimposed_canonicalization branch 2 times, most recently from f73f26e to c8f2ddf Compare March 7, 2025 07:38
@evanlinjin evanlinjin force-pushed the superimposed_canonicalization branch 2 times, most recently from 37fa16d to d309780 Compare March 21, 2025 07:23
@evanlinjin evanlinjin force-pushed the superimposed_canonicalization branch from d309780 to 03f5041 Compare April 17, 2025 05:21
@notmandatory notmandatory moved this to In Progress in BDK Chain Apr 22, 2025
@notmandatory notmandatory moved this from In Progress to Needs Review in BDK Chain Apr 22, 2025
@evanlinjin
Copy link
Member Author

@LLFourn I have a draft PR (bitcoindevkit/bdk_wallet#220) which showcases that this API is enough for bdk_wallet to keep track of unbroadcasted transactions (and not accidentally replace them).

Copy link
Contributor

@LagginTimes LagginTimes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a few consistency nits:

  • Commit message 53d6fa1 needs to be updated to rename CanonicalizationModsCanonicalizationParams.
  • Same change needs to be done in the PR description changelog.

Besides these, this LGTM!

@evanlinjin evanlinjin force-pushed the superimposed_canonicalization branch from 0f5176b to 05fe0d5 Compare May 1, 2025 04:21
@evanlinjin evanlinjin requested a review from LagginTimes May 1, 2025 04:23
@evanlinjin evanlinjin changed the title Introduce canonicalization modifiers. Introduce canonicalization parameters May 1, 2025
evanlinjin and others added 2 commits May 1, 2025 15:24
Introduce `CanonicalizationParams` which is passed in to
`CanonicalIter::new`.

`CanonicalizationParams::assume_canonical` is the only field right now.
This contains a list of txids that we assume to be canonical,
superceding any other canonicalization rules.
@evanlinjin evanlinjin force-pushed the superimposed_canonicalization branch from 05fe0d5 to 53afb35 Compare May 1, 2025 05:25
Copy link
Contributor

@LagginTimes LagginTimes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 53afb35

Copy link
Collaborator

@ValuedMammal ValuedMammal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 53afb35

@ValuedMammal ValuedMammal dismissed LLFourn’s stale review May 1, 2025 14:13

All comments addressed

@ValuedMammal
Copy link
Collaborator

Looks good to me.

@LLFourn Please re-review if you find any issues

@ValuedMammal ValuedMammal merged commit 86cdaf4 into bitcoindevkit:master May 1, 2025
17 checks passed
@github-project-automation github-project-automation bot moved this from Needs Review to Done in BDK Chain May 1, 2025
@ValuedMammal ValuedMammal mentioned this pull request May 1, 2025
39 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api A breaking API change
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Don't double spend created transaction just because they haven't been broadcasted
6 participants