-
Notifications
You must be signed in to change notification settings - Fork 37.7k
rpc: Add function walletestimatefee #22673
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
Conversation
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.
Why a new command while we could just fix estimatesmartfee
?
I don't think it's obviously broken, I think breaking previous behavior
isn't the right thing to do. Arguably we could expose the new behavior
under a flag?
…On Tue, Aug 10, 2021, 2:52 PM darosior ***@***.***> wrote:
***@***.**** commented on this pull request.
Why a new command while we could just fix estimatesmartfee?
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#22673 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABMAFU4KMHRMWPCVASBXE3LT4DECVANCNFSM5B3PJ7OA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
.
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. 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. |
I definitely agree that this overlaps too much with estimatesmartfee to warrant a separate RPC command. Integrating the functionality would be better 👍 |
The problem with estimatesmartfee was that it isn't a wallet RPC, which is required when the reason is say, |
ff1dad5
to
39c3b1a
Compare
Add test for walletestimatefee in feature_fee_estimation.py
39c3b1a
to
3d71755
Compare
RPCResult{ | ||
RPCResult::Type::OBJ, "", "", | ||
{ | ||
{RPCResult::Type::NUM, "feerate", /* optional */ true, "estimate fee rate in " + CURRENCY_UNIT + "/kvB (only present if no errors were encountered)"}, |
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.
We're informally in the process of transitioning from BTC/kvB to sat/vB for fee rates, and of no longer referring to fee rates as fees. For example, it was discussed in November 2020 to soft-replace the settxfee and estimatesmartfee calls with sat/vB equivalents named setfeerate (#20391) and estimatefeerate; the BTC/kvB ones would become hidden RPCs to not break user space.
So, if we do add another fee rate RPC, consider making it denominated in sat/vB units and referring to "fee rates", rather than "fees".
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.
See #20484 (comment) for more info.
Fixing / adapting |
I also agree with updating While fallbackfee is something that only matters to wallets, it isn't tied to specific wallets (all wallets loaded will have the same fallbackfee set) so it isn't necessary to have a wallet rpc just to account for it. Instead, you could add it to |
Should this new behavior be hidden behind a flag or not under estimatesmartfee?
thoughts? |
@pranabp-bit are you planning on reopening this when it is ready, or opening a new PR? Thanks 😊 |
@meshcollider @achow101 @fanquake I went ahead with updating the estimatesmartfee instead of adding a new rpc. Do suggest changes, if any. New PR-rpc: update estimatesmartfee |
…ax of CBlockPolicyEstimator::estimateSmartFee, mempoolMinFee and minRelayTxFee ea31caf update estimatesmartfee rpc to return max of estimateSmartFee, mempoolMinFee and minRelayTxFee. (pranabp-bit) Pull request description: This PR is in response to the issue [#19699](bitcoin/bitcoin#19699). Based on the discussion in the comments of PR [#22673](bitcoin/bitcoin#22673) changes have been made in the `estimatesmartfee` itself such that it takes into account `mempoolMinFee` and `relayMinFee` . Hence it provides a fee estimate that is most likely to be paid by the user in an actual transaction, preventing issues such as [#16072](bitcoin/bitcoin#16072). The test file test/functional/feature_fee_estimation.py has also been updated to check this functionality. ACKs for top commit: meshcollider: re-utACK ea31caf Tree-SHA512: 8f36153a07cbd552c5c13d11d9c6e987a7a555ea4cc83f2573c0c92dd97c706d90c30a7248671437c2f3a836d3272f8fad53d15a5fa6efaa0409ae8009b0a18d
…lockPolicyEstimator::estimateSmartFee, mempoolMinFee and minRelayTxFee ea31caf update estimatesmartfee rpc to return max of estimateSmartFee, mempoolMinFee and minRelayTxFee. (pranabp-bit) Pull request description: This PR is in response to the issue [bitcoin#19699](bitcoin#19699). Based on the discussion in the comments of PR [bitcoin#22673](bitcoin#22673) changes have been made in the `estimatesmartfee` itself such that it takes into account `mempoolMinFee` and `relayMinFee` . Hence it provides a fee estimate that is most likely to be paid by the user in an actual transaction, preventing issues such as [bitcoin#16072](bitcoin#16072). The test file test/functional/feature_fee_estimation.py has also been updated to check this functionality. ACKs for top commit: meshcollider: re-utACK ea31caf Tree-SHA512: 8f36153a07cbd552c5c13d11d9c6e987a7a555ea4cc83f2573c0c92dd97c706d90c30a7248671437c2f3a836d3272f8fad53d15a5fa6efaa0409ae8009b0a18d
This PR is in response to the issue #19699.
walletestimatefee
uses the functionGetMinimumFeeRate
which takes into accountfallbackfee
,estimateSmartFee
,mempoolMinFee
,relayMinFee
. Hence it provides a fee estimate that is most likely to be paid by the user in an actual transaction, preventing issues such as #16072.It takes Confirmation Target (in blocks) and fee estimate mode as input and returns the expected fee rate, reason for estimation, and the block number at which estimate was found (only when the reason is estimatesmartfee) as output.
Test for this function has been added in
test/functional/feature_fee_estimation.py