Skip to content
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

fix: remove deprecated max_satisfaction_weight #1345

Merged

Conversation

storopoli
Copy link
Contributor

@storopoli storopoli commented Feb 15, 2024

Description

Continuation of #1115.
Closes #1036.

  • Change deprecated max_satisfaction_weight to max_weight_to_satisfy
  • Remove #[allow(deprecated)] flags

Notes to the reviewers

I've changed all max_satisfaction_weight() to max_weight_to_satisfy() in Wallet.get_available_utxo() and Wallet.build_fee_bump(). Checking the docs on the miniscript crate for max_weight_to_satisfy has the following note:

We are testing if the underlying descriptor is.segwit() or .is_taproot,
then adding 4WU if true or leaving as it is otherwise.

Another thing, we are not testing in BDK tests for legacy (pre-segwit) descriptors.
Should I also add them to this PR?

Changelog notice

Fixed

Replace the deprecated max_satisfaction_weight from rust-miniscript to max_weight_to_satisfy.

Checklists

All Submissions:

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

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

kaiwolfram

This comment was marked as spam.

Copy link
Member

@evanlinjin evanlinjin left a comment

Choose a reason for hiding this comment

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

Thank you for having a go at this, however the approach here is incorrect.

First off, it's incorrect to add 4WU to only segwit inputs.

Looking at the docs of max_weight_to_satisfy, we need to change the definition of our TX_IN_BASE_WEIGHT to be TxIn::default().segwit_weight().

After that, to make the tests pass, we need to change P2WPKH_SATISFACTION_SIZE to take in to account the scriptSigLen and witnessLen.

I think it's okay to assume all transactions are segwit transactions for now? Unless if someone can figure out how to take away the witness len elegantly (for non-segwit txs).

Comment on lines 2056 to 2059
let segwit_add = match is_segwit {
true => 4,
false => 0,
};
Copy link
Member

Choose a reason for hiding this comment

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

Is the intention here to include the scriptSigLen weight? If so, please name the variable appropriately.

However, non-segwit inputs also have this field. Wouldn't it be correct to always have this addition?

Copy link
Member

Choose a reason for hiding this comment

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

Ignore the comment above. Just remove this and add the extra weights to TX_IN_BASE_WEIGHT.

Copy link
Contributor Author

@storopoli storopoli Mar 1, 2024

Choose a reason for hiding this comment

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

Great, sorry for the missundestanding.
I think I've fixed this in 52d6283

@evanlinjin
Copy link
Member

Can I please have some input on my statement here? Thanks!

I think it's okay to assume all transactions are segwit transactions for now? Unless if someone can figure out how to take away the witness len elegantly (for non-segwit txs).

@storopoli storopoli force-pushed the js/max-weight-deprecation branch 2 times, most recently from 8e91886 to 52d6283 Compare March 1, 2024 10:20
@storopoli
Copy link
Contributor Author

I think it's okay to assume all transactions are segwit transactions for now? Unless if someone can figure out how to take away the witness len elegantly (for non-segwit txs).

I agree. We currently don't test any non-segwit tx anyways...

@evanlinjin
Copy link
Member

I think it's okay to assume all transactions are segwit transactions for now? Unless if someone can figure out how to take away the witness len elegantly (for non-segwit txs).

Because we already assume this:

https://github.com/bitcoindevkit/bdk/blob/master/crates%2Fbdk%2Fsrc%2Fwallet%2Fmod.rs#L1505-L1513

So I think it is okay.

@evanlinjin
Copy link
Member

@storopoli can we please rebase the two commits into one and I'll ACK it.

@storopoli
Copy link
Contributor Author

@storopoli can we please rebase the two commits into one and I'll ACK it.

Done, thanks mate!

Comment on lines 322 to 334
let satisfaction_weight = {
let is_segwit = wallet
.get_descriptor_for_keychain(utxo.keychain)
.is_witness()
|| wallet
.get_descriptor_for_keychain(utxo.keychain)
.is_taproot();
let segwit_add = match is_segwit {
true => 4,
false => 0,
};
descriptor.max_weight_to_satisfy().unwrap() + segwit_add
};
Copy link
Member

Choose a reason for hiding this comment

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

This is still wrong.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry about that. Should be good now.

Copy link
Contributor

@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.

Approach ACK.

For simplicity I think it's fair to assume segwit weight everywhere. Unless someone is doing legacy transactions with hundreds of inputs (which is certainly possible), I don't think you'd notice a difference. We could consider carving out a special case for legacy-only transactions in a future iteration of tx building.

To the note on testing legacy descriptors I don't have an immediate comment on it.

crates/bdk/src/wallet/coin_selection.rs Outdated Show resolved Hide resolved
crates/bdk/src/wallet/mod.rs Show resolved Hide resolved
@evanlinjin
Copy link
Member

@storopoli sorry can you do a rebase on master? thanks

@storopoli storopoli force-pushed the js/max-weight-deprecation branch 2 times, most recently from 446acd2 to 73aacda Compare March 22, 2024 07:45
@storopoli
Copy link
Contributor Author

@storopoli sorry can you do a rebase on master? thanks

Don't worry man. Sure, rebased to master :)

@storopoli storopoli force-pushed the js/max-weight-deprecation branch 2 times, most recently from 1bf5bcf to d2b8e66 Compare March 27, 2024 06:55
- Change deprecated `max_satisfaction_weight` to `max_weight_to_satisfy`
- Remove `#[allow(deprecated)]` flags
- updates the calculations in TXIN_BASE_WEIGHT and P2WPKH_SATISFACTION_SIZE

Update crates/bdk/src/wallet/coin_selection.rs

Co-authored-by: ValuedMammal <valuedmammal@protonmail.com>
Copy link
Member

@evanlinjin evanlinjin left a comment

Choose a reason for hiding this comment

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

ACK 798ed8c

@evanlinjin evanlinjin merged commit 2bb6540 into bitcoindevkit:master Apr 2, 2024
12 checks passed
@storopoli storopoli deleted the js/max-weight-deprecation branch April 2, 2024 11:28
@notmandatory notmandatory mentioned this pull request Apr 12, 2024
25 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 module-wallet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Use max_weight_to_satisfy instead of max_satisfaction_weight
6 participants