-
Notifications
You must be signed in to change notification settings - Fork 38.7k
Wallet: Add max_tx_weight to transaction funding options (take 2)
#29523
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
Wallet: Add max_tx_weight to transaction funding options (take 2)
#29523
Conversation
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. ConflictsNo conflicts as of last run. |
|
Some C.I jobs are failing, putting in draft while I try to address that. |
babbc5c to
8e256fe
Compare
murchandamus
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.
Concept ACK
cddf4e9 to
52e4812
Compare
52e4812 to
53ee67d
Compare
53ee67d to
3a64b3a
Compare
|
Force pushed from 53ee67d to 3a64b3a compare diff
|
furszy
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.
Any chance to turn the first commit into an scripted-diff?
|
Tested ACK 3a64b3a |
3a64b3a to
3d76c37
Compare
The commit message was misleading It's not just renaming I've updated the commit message of the first commit 2706393 |
|
🚧 At least one of the CI tasks failed. Make sure to run all tests locally, according to the Possibly this is due to a silent merge conflict (the changes in this pull request being Leave a comment here, if you need help tracking down a confusing failure. |
3d76c37 to
e7500ec
Compare
|
Rebased to fix conflict after #28366 was merged. |
furszy
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.
few small comments
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.
nit: could replace this line with this constant.
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.
leaving this as is, as I suspect there might be other places that needs to be replaced also.
this and others can come in a separate PR ?
|
thanks for your review @furszy will force push to address this comments shortly. |
1ae619f to
a120fc7
Compare
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.
src/wallet/coinselection.h
Outdated
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.
This change ensures consistency in transaction size and weight calculation
within the wallet and prevents conversion overflow when calculating
max_selection_weight.
Are the inconsistencies because size_t is platform dependent and int is not (at least for the purposes of core because of this: https://github.com/bitcoin/bitcoin/blob/v26.0/src/compat/assumptions.h#L44)?
I still need to digest this comment: #29523 (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.
It's simply just to ensure consistency in transaction size and weight calculation within the wallet and prevents conversion overflow when calculating max_selection_weight as it happened here https://cirrus-ci.com/task/6341256662482944
I think it definitely will be worth it to define a datatype for size in the entire codebase.
But I am limiting this change to affect only the wallet size variables change_output_size, change_spend_size and tx_noinputs_size, because they relate to this PR.
a120fc7 to
b3ac117
Compare
…x weight 72b2268 wallet: notify when preset + automatic inputs exceed max weight (furszy) Pull request description: Small change. Found it while finishing my review on #29523. This does not interfere with it. Basically, we are erroring out early when the automatic coin selection process exceeds the maximum weight, but we are not doing so when the user-preselected inputs combined with the wallet-selected inputs exceed the maximum weight. This change avoids signing all inputs before erroring out and introduces test coverage for `fundrawtransaction`. ACKs for top commit: achow101: ACK 72b2268 tdb3: re ACK for 72b2268 rkrux: tACK [72b2268](72b2268) ismaelsadeeq: utACK 72b2268 Tree-SHA512: d77be19231023383a9c79a5d66b642dcbc6ebfc31a363e0b9f063c44898720a7859ec211cdbc0914ac7a3bfdf15e52fb8fc20d97f171431f70492c0f159dbc36
furszy
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.
Code reviewed b3ac1179ff90f, getting closer. Left few topics.
src/wallet/rpc/spend.cpp
Outdated
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.
Not sure about using tx_size, we would be returning an estimation of the final size of tx. Not the real/current tx weight.
What about getting the current tx weight by serializing the CMutableTransaction object that appears inside FinishTransaction and explain in the RPC return value description that the returned weight will not be the final one if the transaction is not complete.
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.
Interesting, I agree with this point. Returning the exact size of the transaction would make the RPC definition more robust.
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.
This commit (along with this^ suggestion) b3ac117 can be a separate PR as well, doesn't seem necessary for this PR to be merged if I didn't miss anything.
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.
Yes it's not needed.
I removed this commit
This can come as a separate PR, the size output can also be added to the other funding RPC's?
…ght` name - This commit renames the coin selection algorithms input parameter `max_weight` to `max_selection_weight` for clarity. The parameter represent the maximum weight of the UTXOs the coin selection algorithm should select, not the transaction maximum weight. - The commit updates the parameter docstring to provide correct description. - Also updates coin selection unit and fuzzing test variables to match the new name.
`CoinGrinder` will also produce change output, listing all the Coin selection algorithms that produces change output is not maintainable, just infer that remaining algorithms all might produce change.
…_size` and `tx_noinputs_size` to `int` - This change ensures consistency in transaction size and weight calculation within the wallet and prevents conversion overflow when calculating `max_selection_weight`.
b3ac117 to
d8febf6
Compare
This allows a transaction's weight to be bound under a certain weight if possible and desired. This can be beneficial for future RBF attempts, or whenever a more restricted spend topology is desired. Co-authored-by: Greg Sanders <[email protected]>
d8febf6 to
734076c
Compare
|
Thanks for the reviews @furszy @rkrux Force-pushed from b3ac1179ff90fe261af4e6dc9c7af64e1518b435 to d8febf6d9ea018cf8e980ee036fb5ccd8ea8887a Changes:
|
furszy
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.
utACK 734076c
|
|
||
| coin_selection_params.m_max_tx_weight = coin_control.m_max_tx_weight.value_or(MAX_STANDARD_TX_WEIGHT); | ||
| int minimum_tx_weight = MIN_STANDARD_TX_NONWITNESS_SIZE * WITNESS_SCALE_FACTOR; | ||
| if (coin_selection_params.m_max_tx_weight.value() < minimum_tx_weight || coin_selection_params.m_max_tx_weight.value() > MAX_STANDARD_TX_WEIGHT) { |
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.
In 734076c:
nano nit: shorter
| if (coin_selection_params.m_max_tx_weight.value() < minimum_tx_weight || coin_selection_params.m_max_tx_weight.value() > MAX_STANDARD_TX_WEIGHT) { | |
| if (*coin_selection_params.m_max_tx_weight < minimum_tx_weight || *coin_selection_params.m_max_tx_weight > MAX_STANDARD_TX_WEIGHT) { |
rkrux
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.
reACK 734076c
Ran make and functional tests, all successful.
@ismaelsadeeq This diff comparison b3ac117..734076c contains a lot of unrelated changes though.
Yes that's because of the recent rebase. |
|
ACK 734076c |
This PR taken over from #29264
The PR added an option
max_tx_weightto transaction funding RPC's that ensures the resulting transaction weight does not exceed the specifiedmax_tx_weightlimit.If
max_tx_weightis not givenMAX_STANDARD_TX_WEIGHTis used as the max threshold.This PR addressed outstanding review comments in #29264
For more context and rationale behind this PR see https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418/11?u=instagibbs