Skip to content

Conversation

pranabp-bit
Copy link
Contributor

@pranabp-bit pranabp-bit commented Aug 10, 2021

This PR is in response to the issue #19699.

walletestimatefee uses the function GetMinimumFeeRate which takes into account fallbackfee, 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

@fanquake fanquake requested a review from instagibbs August 10, 2021 06:39
@pranabp-bit pranabp-bit changed the title Add function walletestimatefee rpc: Add function walletestimatefee Aug 10, 2021
Copy link
Member

@darosior darosior left a 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?

@instagibbs
Copy link
Member

instagibbs commented Aug 10, 2021 via email

@DrahtBot
Copy link
Contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #22513 (rpc: Allow walletprocesspsbt to sign without finalizing by achow101)

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.

@meshcollider
Copy link
Contributor

I definitely agree that this overlaps too much with estimatesmartfee to warrant a separate RPC command. Integrating the functionality would be better 👍

@pranabp-bit
Copy link
Contributor Author

pranabp-bit commented Aug 10, 2021

The problem with estimatesmartfee was that it isn't a wallet RPC, which is required when the reason is say, fallbackfee .
I felt that if a user is able to call a command from the wallet itself and it uses the same functions which are used by commands like sendtoaddress and sendmany , it would minimize the possibility of a strange high feerate like #16072
Do suggest what the best way to move forward would be.

Add test for walletestimatefee in feature_fee_estimation.py
RPCResult{
RPCResult::Type::OBJ, "", "",
{
{RPCResult::Type::NUM, "feerate", /* optional */ true, "estimate fee rate in " + CURRENCY_UNIT + "/kvB (only present if no errors were encountered)"},
Copy link
Member

@jonatack jonatack Aug 10, 2021

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

Copy link
Member

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.

@fanquake
Copy link
Member

Do suggest what the best way to move forward would be.

Fixing / adapting estimatesmartfee, not adding a new RPC.

@achow101
Copy link
Member

I also agree with updating estimatesmartfee rather than a whole new rpc.

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 WalletClient (have WalletClient also parse the -fallbackfee option) and retrieve it from there via NodeContext. When wallets are disabled, NodeContext.wallet_client will just be nullptr, and in that situation, -fallbackfee couldn't have been set and so doesn't matter for the fee estimation.

@instagibbs
Copy link
Member

Should this new behavior be hidden behind a flag or not under estimatesmartfee?

  1. fallbackfee is opt-in only now, so as long as a user doesn't put it into their conf file, it won't be hit
  2. minrelay fee is reasonable change in behavior by default to me

thoughts?

@meshcollider
Copy link
Contributor

@pranabp-bit are you planning on reopening this when it is ready, or opening a new PR? Thanks 😊

@pranabp-bit
Copy link
Contributor Author

@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

meshcollider added a commit to bitcoin-core/gui that referenced this pull request Sep 28, 2021
…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
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Sep 28, 2021
…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
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Aug 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants