Discountinuously cached addresses warning.

[buhtignew]

I think that for the moment in case of discontinuous address caching there is no way to know whether the address was discontinuously cached or not.

Which may case some issue.

For instance if I run address cache mmBwLVyqZWuUDuTpmmpzBvT41azKBevZhh -e and then address cache mmBwLVyqZWuUDuTpmmpzBvT41azKBevZhh -s 3465 -b 100 -f and address cache mmBwLVyqZWuUDuTpmmpzBvT41azKBevZhh -s 3767 -b 100 -f the result of the transaction list mmBwLVyqZWuUDuTpmmpzBvT41azKBevZhh -x -l -f 3465 -e 3867 won't include the block 3736 (which I can see if I run address cache mmBwLVyqZWuUDuTpmmpzBvT41azKBevZhh -e and address cache mmBwLVyqZWuUDuTpmmpzBvT41azKBevZhh -s 3465 -b 400 -f).

Moreover if after I've discontinuously cached the address on two different intervals (like above where I have only intervals from 3465 to 3565 and from 3767 to 3867 scanned) I can run address cache mmBwLVyqZWuUDuTpmmpzBvT41azKBevZhh and the caching will start from the block 3868 as if the previous scanning were continuous.

Since the user may forget to have done a discontinuous scanning previously, I think it may worth considering a warning in such a case.
There is of course no need to remember all the start and end hashes of all the cached intervals, since the address cache command is perfectly conscious when the discontinuous scanning is performed, for instance in case I run address cache mmBwLVyqZWuUDuTpmmpzBvT41azKBevZhh -s 4065 -b 50 -f there is the following line in the output:

Forcing to cache block heights as required. Last stored block was 3867, continuing from block 4065 on.

So it would be enough to store just an additional bit of information in the blocklocator.json file, recording whether the scanning was discontinuous or not and to output a warning in case it was, both for the address cache as for the transaction list command if run with the -l flag.

What do you think?

[d5000]

I'm thinking about it, taking into account the use cases for discontinuous caching.

I think the main use case are addresses where the user knows they were created at a certain date. These would be cached from a block near this date, but then continuously. P2TH addresses are an even clearer example, here we know exactly when they were created - at the deck spawn transaction. So we don't need to cache them from block 0.

This use case would only seldom lead to situations where a warning would be appropiate. So my opinion is that in this case the user should be warned when he intends to cache the address with a different start block than the genesis block (0), but not when he uses the commands like transaction list. He should only be informed decently about the starting block, just like the other info which is displayed during many commands.

If the user however tries to "calculate" when he used the address, e.g. if it's a cold storage address, and caches discontiuously near the dates he thinks there were transactions, then this is more prone to errors and thus in this case there should be a warning also during operation.

So perhaps the best solution for the entries in blocklocator.json, without clogging the file too much, could be:

1. add a "start" parameter to all addresses where the caching started at a higher block height than 0, with the block height where caching started. The "start" parameter, when available, should always be shown in commands like transaction list or address cache -v (excluding -q options).

2. add a boolean "discontinuous" parameter like you proposed to the address entries in where there are gaps between the caching phases. This one should trigger a stronger warning, so the user knows the data may be wrong if he messed up his caching.

That's my take on this issue for now, it would not require much time. The blocklocator.json's created during testing of course afterwards would have to be recreated. I guess this would be even more what you requested ;)

[buhtignew]

Indeed :-)