importdescriptors always rescans #31263

1. 
   gmart7t2 commented at 12:33 pm on November 9, 2024: none

   Is there an existing issue for this?

   • I have searched the existing issues

   Current behaviour

   Running importdescriptors with timestamp: now rescans the last 2 hours worth of blocks.

   The docs say that ‘“now” can be specified to bypass scanning’ but that doesn’t appear to be true:

   0"timestamp": timestamp | "now",    (integer / string, required) Time from which to start rescanning the blockchain for this descriptor, in UNIX epoch time
   1                                   Use the string "now" to substitute the current synced blockchain time.
   2                                   "now" can be specified to bypass scanning, for outputs which are known to never have been used, and
   3                                   0 can be specified to scan the entire blockchain. Blocks up to 2 hours before the earliest timestamp
   4                                   of all descriptors being imported will be scanned as well as the mempool.
   

   I also tried using timestamps several days into the future, but still see about 2 hours worth of blocks being rescanned. I want to be able to import a description without triggering any block rescan.

   Expected behaviour

   I expect the behavior to match the docs.

   Steps to reproduce

   1. Run importdescriptors with the timestamp set to “now”
   2. See in the log that the wallet rescanned some blocks

   Relevant log output

   No response

   How did you obtain Bitcoin Core

   Compiled from source

   What version of Bitcoin Core are you using?

   v28.0

   Operating system and version

   Some kind of Debian

   Machine specifications

   No response

2. maflcko added the label Feature on Nov 9, 2024
3. maflcko added the label Wallet on Nov 9, 2024
4. maflcko added the label RPC/REST/ZMQ on Nov 9, 2024
5. 
   furszy commented at 4:40 pm on November 9, 2024: member

   The docs say that ‘“now” can be specified to bypass scanning’ but that doesn’t appear to be true

   The message also specify that “Blocks up to 2 hours before the earliest timestamp of all descriptors being imported will be scanned as well as the mempool”. This occurs regardless of the provided timestamp. It serves as a grace period to account for possible variations in block times.

6. achow101 closed this on Nov 9, 2024

   ---

7. 
   gmart7t2 commented at 11:26 pm on November 11, 2024: none

   Even when the earliest timestamp specified is a week in the future it still rescans blocks from 2 hours ago.

   That goes against what the documentation string says.

8. 
   achow101 commented at 0:03 am on November 12, 2024: member

   It doesn’t make sense for a user to import descriptors with a future timestamp. If the timestamp is greater than “now”, then the timestamp for rescanning will be “now”.

   importdescriptors will always rescan a few blocks. The documentation should be updated if that is confusing.

9. 
   gmart7t2 commented at 6:06 pm on November 15, 2024: none

   Here’s the use case:

   I have a descriptor that I know has never been used. I want to import it. I don’t need any rescan, because I know it hasn’t been used.

   In this case I don’t care about variations in block times because 2 hours before “never used” is still “never used”.

10. 
    sipa commented at 6:18 pm on November 15, 2024: member

    I don’t think it’s unreasonable to have a way to signal “never used”.
11. 
    casey commented at 0:05 am on November 17, 2024: contributor

    Something else that’s useful to note is that even a short rescan, on a weak or otherwise loaded machine, can cause RPC calls to start timing out. So avoiding it when unnecessary is useful.
12. 
    furszy commented at 10:48 pm on November 17, 2024: member

    Something else that’s useful to note is that even a short rescan, on a weak or otherwise loaded machine, can cause RPC calls to start timing out.

    Just a recommendation. Can make the rescan lighter and faster by enabling -blockfilterindex. It will avoid reading and traversing blocks with no matching elements.

13. 
    gmart7t2 commented at 1:44 am on November 18, 2024: none

    I have that, and it does make it faster. But I still get RPC timeouts when the machine is loaded, particularly if the wallet already has a lot of descriptors in it. It doesn’t only rescan for the one(s) I am adding, but also for all the pre-existing descriptors in the wallet.
14. achow101 reopened this on Nov 18, 2024

    ---

15. 
    furszy commented at 2:03 am on November 18, 2024: member

    I have that, and it does make it faster. But I still get RPC timeouts when the machine is loaded, particularly if the wallet already has a lot of descriptors in it. It doesn’t only rescan for the one(s) I am adding, but also for all the pre-existing descriptors in the wallet.

    Yes. Thats something I already have in my TO DO list. It requires restructuring the rescan process.

Contributors
gmart7t2 furszy achow101 sipa casey

Labels
Feature Wallet RPC/REST/ZMQ