Fresh download of blockchain in unclosed instance fails estimatesmartfee. #22404

issue dscotese opened this issue on July 5, 2021
  1. dscotese commented at 2:46 PM on July 5, 2021: contributor

    <!-- This issue tracker is only for technical issues related to Bitcoin Core. General bitcoin questions and/or support requests are best directed to the Bitcoin StackExchange at https://bitcoin.stackexchange.com. For reporting security issues, please read instructions at https://bitcoincore.org/en/contact/. If the node is "stuck" during sync or giving "block checksum mismatch" errors, please ensure your hardware is stable by running memtest and observe CPU temperature with a load-test tool such as linpack before creating an issue! -->

    <!-- Describe the issue -->

    If you start a fresh copy of bitcoin-qt without any blockchain data, wait until the entire blockchain is downloaded, and then open a console window and try estimatesmartfee, the answer is

    {
      "errors": [
        "Insufficient data or no feerate found"
      ],
      "blocks": 1
    }
    

    <!--- What behavior did you expect? -->

    I expected n estimate of the fee appropriate to the passed in number of blocks using the fees from the recently downloaded (and therefore newest) blocks.

    I will not try to reproduce this issue because it takes several hours to download the blockchain.

    This is Windows 10 with Bitcoin Core 0.21.1.

    I don't believe this is a failure of the system or an anomaly in the environment, but rather an oversite in the processing of blocks when "catching up." I suspect that the process recognizes that the block received has been around a while and therefore doesn't bother updating the information required to answer estimatesmartfee. This makes sense because tracking that information for every received block would slow down the process too much.

    Proposed solution: If one of the startup tasks were to identify the blockheight at which tracking fees would become useful, then the process could start tracking them once the blockheight was there. Otherwise, other layers that rely on estimatesmartfee (like ACINQ's Eclair Lightning node) have to wait an extra hour even though bitcoind has all the information it needs.

    If there is information required by estaimatesmartfee that is not available to a node which has just finished downloading the blockchain, please add a comment explaining what it is.

  2. dscotese added the label Bug on Jul 5, 2021
  3. jarolrod commented at 2:48 PM on July 5, 2021: member

    you have to wait around for a couple of blocks after being synced before fee estimation will work

  4. MarcoFalke closed this on Jul 5, 2021

  5. dscotese commented at 4:29 PM on July 5, 2021: contributor

    you have to wait around for a couple of blocks after being synced before fee estimation will work

    I don't. I can go to any block explorer and compute a fee estimate from the last several blocks and their timestamps. The code can do the same thing, but it doesn't. Perhaps someone will explain why it doesn't.

  6. MarcoFalke commented at 4:35 PM on July 5, 2021: member

    Deriving the fees from the blocks makes it susceptible to miner attacks. The Bitcoin Core fee estimation uses the mempool transactions.

  7. achow101 commented at 4:37 PM on July 5, 2021: member

    Your assumption about how Bitcoin Core's fee estimation is incorrect. Bitcoin Core estimates the fee by observing how long transactions stay in its mempool. It tracks the fee rate for an unconfirmed transaction and how many blocks pass from the time it entered the mempool to when it is finally included in a block. This is how it can give estimate for different block targets. So in order for fee estimation to work, your node must have a mempool and must have seen transactions go from unconfirmed to confirm. It cannot derive fee information from just blocks. Doing so would allow miners to rig fee estimation by packing a couple blocks full of super high fee transactions and cause such fee estimators to estimate extremely high fees unnecessarily.

  8. DrahtBot locked this on Aug 18, 2022

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: 2026-04-21 21:14 UTC

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