-
Notifications
You must be signed in to change notification settings - Fork 35.9k
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
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
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
|
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
b24b7a9
to
845d16c
Compare
Rebased to fix conflict after #28366 was merged. |
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
@@ -48,6 +48,7 @@ | |||
|
|||
MAX_BLOCK_SIGOPS = 20000 | |||
MAX_BLOCK_SIGOPS_WEIGHT = MAX_BLOCK_SIGOPS * WITNESS_SCALE_FACTOR | |||
MAX_STANDARD_TX_WEIGHT = 400000 |
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.
size_t change_output_size = 0; | ||
int change_output_size = 0; |
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
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 b3ac117, getting closer. Left few topics.
src/wallet/rpc/spend.cpp
Outdated
|
||
return FinishTransaction(pwallet, options, rawTx); | ||
auto result = FinishTransaction(pwallet, options, rawTx); | ||
result.pushKV("weight", tx_size.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.
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 <gsanders87@gmail.com>
d8febf6
to
734076c
Compare
Thanks for the reviews @furszy @rkrux Force-pushed from b3ac117 to d8febf6 Changes:
|
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) { |
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_weight
to transaction funding RPC's that ensures the resulting transaction weight does not exceed the specifiedmax_tx_weight
limit.If
max_tx_weight
is not givenMAX_STANDARD_TX_WEIGHT
is 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