Improve documentation of estimatesmartfee #18217

issue stevenroose openend this issue on February 28, 2020
  1. stevenroose commented at 0:17 am on February 28, 2020: contributor
     0RPCHelpMan{"estimatesmartfee",
     1    "\nEstimates the approximate fee per kilobyte needed for a transaction to begin\n"
     2    "confirmation within conf_target blocks if possible and return the number of blocks\n"
     3    "for which the estimate is valid. Uses virtual transaction size as defined\n"
     4    "in BIP 141 (witness data is discounted).\n",
     5    {
     6        {"conf_target", RPCArg::Type::NUM, RPCArg::Optional::NO, "Confirmation target in blocks (1 - 1008)"},
     7        {"estimate_mode", RPCArg::Type::STR, /* default */ "CONSERVATIVE", "The fee estimate mode.\n"
     8"                   Whether to return a more conservative estimate which also satisfies\n"
     9"                   a longer history. A conservative estimate potentially returns a\n"
    10"                   higher feerate and is more likely to be sufficient for the desired\n"
    11"                   target, but is not as responsive to short term drops in the\n"
    12"                   prevailing fee market.  Must be one of:\n"
    13"       \"UNSET\"\n"
    14"       \"ECONOMICAL\"\n"
    15"       \"CONSERVATIVE\""},
    16    },
    17    RPCResult{
    18"{\n"
    19"  \"feerate\" : x.x,     (numeric, optional) estimate fee rate in " + CURRENCY_UNIT + "/kB\n"
    20"  \"errors\" : [ str... ] (json array of strings, optional) Errors encountered during processing\n"
    21"  \"blocks\" : n         (numeric) block number where estimate was found\n"
    22"}\n"
    23"\n"
    24"The request target will be clamped between 2 and the highest target\n"
    25"fee estimation is able to return based on how long it has been running.\n"
    26"An error is returned if not enough transactions and blocks\n"
    27"have been observed to make an estimate for any number of blocks.\n"
    28    },
    29    RPCExamples{
    30        HelpExampleCli("estimatesmartfee", "6")
    31    },
    32}.Check(request);
    

    To me it’s not very clear what the "blocks" return value actually means.

    • Is it supposed to be a block height or a block height
    • Is it the block height at which a tx with the given fee is supposed to go in?
    • Or does it indicate for how long I can reliably keep using the same estimation?

    Some improvements of this documentation would be appreciated. If someone can explain it here, I can make the PR myself if that’s preferred.

  2. stevenroose added the label Bug on Feb 28, 2020
  3. fanquake added the label Docs on Feb 28, 2020
  4. fanquake added the label RPC/REST/ZMQ on Feb 28, 2020
  5. maflcko commented at 4:24 pm on February 28, 2020: member
    IIRC it is the conf_target that was passed in, but it might not be possible to find a result for that exact conf_target, so the actual one is returned.
  6. jarolrod commented at 10:20 pm on January 16, 2021: member

    the blocks return value is a numeric value indicating the amount of blocks the estimated fee is good for.

    It should be the conf_target that was passed in, but as mentioned it might not be possible to get an estimate for that target. If it is not possible then the fee is based around the closest it can get to the conf_target and the number passed back will not be the conf_target you passed in.

    For more context, the comment on CBlockPolicyEstimator::estimateSmartFee reads:

    Estimate feerate needed to get be included in a block within confTarget blocks. If no answer can be given at confTarget, return an estimate at the closest target where one can be given. 'conservative' estimates are valid over longer time horizons also.

  7. jonatack commented at 10:32 pm on January 16, 2021: member
    Thanks for bubbling this up. Per the plan in #20484 (comment) of which #20391 and #20546 are the first steps, settxfee and estimatesmartfee may become hidden RPCs in favor of new setfeerate and estimatefeerate ones in sat/B. I’ll keep this issue in mind when writing (and updating) the help documentation of the four.
  8. adamjonas commented at 0:33 am on August 2, 2022: member
    @jonatack was this addressed by #21786?
  9. jonatack commented at 3:58 pm on August 4, 2022: member
    @adamjonas thank you for the reminder – that PR unblocked a hurdle to the plan in #20484 (comment) and am picking up #20391 again.
  10. adamjonas commented at 7:16 pm on March 17, 2023: member
    @jonatack looks like #20391 was closed. Is there a commit to cherry-pick that might close this issue?
  11. ismaelsadeeq commented at 3:06 pm on July 25, 2024: member

    I opened #30525, which includes a commit that attempts to clarify the blocks result in the estimatesmartfee RPC.

    I don’t think the bug label applies to this issue.

  12. ismaelsadeeq commented at 6:45 pm on September 14, 2024: member

    The previous attempt to fix in #30525 in commit https://github.com/bitcoin/bitcoin/commit/e387642f36ba01e45656875d8bde7b021ed28556 was not successful, so I am bringing this here as an attempt to move this issue forward i.e closed/fixed

    @glozow said in #30525 (review): I think the previous text is clear and not inaccurate, so I’m wondering whether this last commit is necessary.

  13. maflcko commented at 9:01 am on September 23, 2024: member
    Closing for now. However, if there are still questions about the documentation, or if there are ideas to improve it, please leave a comment below, or create a pull request, or a new issue.
  14. maflcko closed this on Sep 23, 2024


github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-11-23 21:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me