Allow specifying wallet rescan timestamp when restoring

[casey]

We recently fixed #1589, which triggers a wallet rescan when a wallet is restored from a descriptor. However, rescans are expensive. We should allow the user to optinally provide a timestamp or date when restoring, in order to avoid rescanning the entire chain.

Maybe something like:

ord wallet restore --timestamp N

Where N is either a unix timestamp, or a YYYY-MM-DD date. If the user provides a date, we should round it to midnight the previous day, to avoid issues with time zones.

[gmart7t2]

I would like to be able to specify no rescan at all as an option (both for wallet restore and wallet create).

When my computer is busy, the default small rescan can take long enough to cause the RPC to time out. This is especially annoying during wallet creation, since you end up not seeing the new seed phrase, but even during wallet restore sometimes you end up with only one of the 2 descriptors being added to the wallet.

[casey]

When you say "default small rescan", what do you mean?

I definitely agree that it should be possible to skip a rescan. Maybe with --timestamp now?

[gmart7t2]

Currently when you use "ord wallet restore", a few blocks are rescanned. Check the bitcoind logs to see it.

Example:

2024-11-08T14:49:20Z Using SQLite Version 3.40.1
2024-11-08T14:49:20Z Using wallet /home/user/.bitcoin/wallets/oil
2024-11-08T14:49:20Z init message: Loading wallet…
2024-11-08T14:49:20Z [oil] Wallet file version = 10500, last client version = 280000
2024-11-08T14:49:20Z [oil] Legacy Wallet Keys: 0 plaintext, 0 encrypted, 0 w/ metadata, 0 total.
2024-11-08T14:49:20Z [oil] Descriptors: 0, Descriptor Keys: 0 plaintext, 0 encrypted, 0 total.
2024-11-08T14:49:20Z [oil] Setting minversion to 169900
2024-11-08T14:49:20Z [oil] Wallet completed loading in               6ms
2024-11-08T14:49:20Z [oil] setKeyPool.size() = 0
2024-11-08T14:49:20Z [oil] mapWallet.size() = 0
2024-11-08T14:49:20Z [oil] m_address_book.size() = 0
2024-11-08T14:49:22Z [oil] Setting spkMan to active: id = 8f0e915d84961529e794fbbf58e6bb6e6ae32ea562f0d22a7180e498a9060c84, type = bech32m, internal = false
2024-11-08T14:49:22Z [oil] RescanFromTime: Rescanning last 17 blocks
2024-11-08T14:49:22Z [oil] Rescan started from block 000000000000000000027cba816b1d7d0c95e406b07a98bff57ad890b82d4bb4... (fast variant using block filters)
2024-11-08T14:49:22Z [oil] Scanning current mempool transactions.
2024-11-08T14:49:22Z [oil] Rescan completed in             193ms
2024-11-08T14:49:24Z [oil] Setting spkMan to active: id = dbe3233a92a092fbf769b2c24b18a25d1542fa52287ff11f446b3fa659f0c8fa, type = bech32m, internal = true
2024-11-08T14:49:24Z [oil] RescanFromTime: Rescanning last 17 blocks
2024-11-08T14:49:24Z [oil] Rescan started from block 000000000000000000027cba816b1d7d0c95e406b07a98bff57ad890b82d4bb4... (fast variant using block filters)
2024-11-08T14:49:24Z [oil] Scanning current mempool transactions.
2024-11-08T14:49:24Z [oil] Rescan completed in             430ms

So I guess by "default small rescan" I mean 17 blocks in this case. It might be whichever blocks were mined in the last 2 hours. I would like a way of skipping the rescan completely.

[gmart7t2]

Maybe this is a bitcoind issue, not ord.

I just tried bitcoin-cli importdescriptors with timestamp: now and it rescanned 16 blocks.

The docs say that '"now" can be specified to bypass scanning' but that doesn't appear to be true:

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

[gmart7t2]

Even specifying a timestamp years into the future doesn't prevent a small number of blocks (currently 15) being rescanned.

[casey]

I'm guessing I know what's going on. Timestamps are probably rounded back some number of hours into the past, to avoid missing transactions if the user is slightly off with their timestamp. If now gets clamped to the current time, then rounded back, for example to the previous day, then you might see this. Does the number of blocks scanned depend on the time of day?

[casey]

Consider opening an issue on bitcoin core. Doing any rescans for now definitely seems undesirable.

[gmart7t2]

Bitcoin block timestamps don't have to be all that accurate. Times up to 2 hours ahead of the current network adjusted time are accepted. That's probably the reason for rescanning the last 2 hours of blocks.

Does the number of blocks scanned depend on the time of day?

Not directly. I think it depends on something like how many blocks have timestamps within 2 hours of the most recent block's timestamp.

Consider opening an issue on bitcoin core.

I'll do that. But I expect if anything they will fix the documentation to match the code.

[gmart7t2]

It's issue 31263. I don't know if linking it to this evil spammy scammy ordinals issue is a good idea.

[gmart7t2]

Consider opening an issue on bitcoin core

I'll do that. But I expect if anything they will fix the documentation to match the code.

Did I call it or what?