-
Notifications
You must be signed in to change notification settings - Fork 37.7k
Wallet: Add maxfeerate
wallet startup option
#29278
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
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code Coverage & BenchmarksFor details see: https://corecheck.dev/bitcoin/bitcoin/pulls/29278. 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. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. LLM Linter (✨ experimental)Possible typos and grammar issues:
drahtbot_id_4_m |
maxfeerate
and maxburnamount
startup option and use maxfeerate
to check max wallet tx feeratemaxfeerate
and maxburnamount
startup option
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 mentioned adding a maxfeerate
option in #29220, but I was more imagining it as a wallet-only option. I don't think that wallet configurations should bleed into how the node RPCs function. Instead, the interaction there should be for wallet to pass it as a param to BroadcastTransaction
when the it submits a tx to the node.
I'm also not sure about maxburnamount
being a node-wide config (#29217 (comment))
Thanks @glozow for your review. |
I agree this feels more like it should be a wallet option. |
b9f2ddc
to
0c9e0c5
Compare
🚧 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. |
maxfeerate
and maxburnamount
startup optionmaxfeerate
wallet startup option
maxfeerate
wallet startup optionmaxfeerate
wallet startup option
Forced pushed from 2576efc to 0c9e0c5 Compare the 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.
It seems odd to me that we would ever have maxtxfee
and maxfeerate
set together as they seem to cover entirely different scenarios.
For maxtxfee
, a user is expressing "I don't or care what my transaction size is but I know I never want to spend more than X in total fees."
For maxfeerate
as user is expressing "I know that my transactions will vary a lot in size, so I don't know what the total fees will be, but I do know that I don't want to pay more than X sats/per vbyte."
I am struggling to think of a scenario where it makes sense to combine them. On the other hand, if I set a maxtxfee
of Y and a maxfeerate
of X, there input sets that are valid for Y but not valid for X and also inputs that are valid for X but not for Y.
What do you think about only letting the user set one or the other? Or is there a use case for caring about the total fees you pay AND caring about the sats per vbyte you pay that I'm not understanding?
I think it makes sense to have both. I could have a |
But in this example, if you typo'd a feerate orders of magnitude higher, your Seems less footgunny to only let the user set one or the other (and then as a belt and suspenders still check the defaults for both, regardless of what is set?). But I might be overthinking this.. just seems really gross to have to now consider both of these in coin selection, especially if a user sets wonky values. |
Thank you for your comments @josibake @glozow @achow101 , will address review comments shortly.
I don't think this is true; it depends on what your This is not likely to occur. I did a manual test on master. When I set However, in some cases where you set a low
On this branch, if I set my
IIUC Maybe I should differentiate between the two error messages and make it more verbose, so that users can know which one is hit and adjust if its not intentional. |
6dec2d4
to
258a7fa
Compare
258a7fa
to
31a1609
Compare
Rebased to fix merge conflict. |
31a1609
to
c2db218
Compare
908710d
to
29db50d
Compare
🚧 At least one of the CI tasks failed. HintsTry to run the tests locally, according to the documentation. However, a CI failure may still
Leave a comment here, if you need help tracking down a confusing failure. |
29db50d
to
b592d27
Compare
-BEGIN VERIFY SCRIPT- git grep -l "m_default_max_tx_fee" src | xargs sed -i "s/m_default_max_tx_fee/m_max_tx_fee/g" -END VERIFY SCRIPT- - The value is not always the default but can be configured during startup so `m_max_tx_fee` is the right name not `m_default_max_tx_fee`.
- Also update `-maxapsfee` option from `max_fee` to `max_aps_fee`. This fixes the ambiguity in the variable name.
- The commits adds a new wallet startup option `-maxfeerate` - The value will be used as the upper limit of wallet transaction fee rate. - The commit updates all instances where `-maxtxfee` value is utilized to check wallet transactions fee rate upper limit to now use `-maxfeerate` value. - `settxfee` RPC now only check if the fee rate user set is less `minrelaytxfee`, less than wallet min fee, or whether it exceed `maxfeerate`. We should not check whether `settxfee` RPC respects `maxtxfee` limit in in the functional test because its not enforced. We now only check if `settxfee` respects `maxfeerate` limit.
- `BroadcastTransaction` now accepts a fee rate limit as an additional input parameter. It ensures that the transaction with fee rate exceeding the specified limit are not added to mempool and not broadcasted to peers. - This will allow differentiating between the error messages when either `-maxtxfee` or `maxfeerate` is hit. - `TestSimpleSpend` creates transaction with base fee of `DEFAULT_TRANSACTION_MAXFEE`, since we now also check fee rate limit in broadcastTransaction, creating transaction with the base fee of `DEFAULT_TRANSACTION_MAXFEE` will prevent the transaction from being broadcasted because its fee rate will be above `DEFAULT_MAX_TRANSACTION_FEERATE`, hence update the maximum during broadcast to be the expected fee rate of the transaction.
- This distinguishes maxfeerate and maxtxfee error messages.
- This commit prevents the wallet from creating transactions above `maxfeerate`, and tests the new functionality.
… less than `minrelaytxfee` - Wallet prevents creating transactions with fee rates lower than `-minrelaytxfee`. Also prevents creating a transaction with a base fee above `-maxtxfee`. - Warn user if a 1kvb transaction, with a base fee set to `-maxtxfee`, has a fee rate less than `-minrelaytxfee`. It is likely that some transactions with fee rates greater than or equal to the `-minrelaytxfee` will also likely exceed `-maxtxfee`, the wallet won't be able to create transactions.
b592d27
to
4d6de3c
Compare
This PR fixes #29220
The PR adds a wallet
-maxfeerate
startup option, as the upper limit of wallet transactions fee rate.This fixes the ambiguity of using
maxtxfee
value to check the upper limit of transactions fee rate.Wallet will not create a transaction with fee rate above
maxfeerate
value. And you can not set wallet fee rate withsettxfee
RPC abovemaxfeerate
value.This PR adds a functional test that ensure the behavior is enforced.