For a datapoint, it took about 2.25 hours at current height to check all the blocks. I think the status update every 1k blocks is nice.

01/18/22 20:51:57 Loading block index...
01/18/22 20:52:22 LoadBlockIndex(): hashBestChain=0000000000000000000880d32fd1321a69593493cd2b18d654350741bfbd6a55 height=719329
01/18/22 20:52:22 CheckDiskBlocks() at height=719329 ...
01/18/22 20:52:40 CheckDiskBlocks() at height=718329 ...
01/18/22 20:53:00 CheckDiskBlocks() at height=717329 ...
01/18/22 20:53:18 CheckDiskBlocks() at height=716329 ...
01/18/22 20:53:39 CheckDiskBlocks() at height=715329 ...
01/18/22 20:53:59 CheckDiskBlocks() at height=714329 ...
01/18/22 20:54:18 CheckDiskBlocks() at height=713329 ...
01/18/22 20:54:36 CheckDiskBlocks() at height=712329 ...
01/18/22 20:54:57 CheckDiskBlocks() at height=711329 ...
01/18/22 20:55:17 CheckDiskBlocks() at height=710329 ...
01/18/22 20:55:37 CheckDiskBlocks() at height=709329 ...

...

01/18/22 23:09:27 CheckDiskBlocks() at height=10329 ...
01/18/22 23:09:27 CheckDiskBlocks() at height=9329 ...
01/18/22 23:09:27 CheckDiskBlocks() at height=8329 ...
01/18/22 23:09:27 CheckDiskBlocks() at height=7329 ...
01/18/22 23:09:27 CheckDiskBlocks() at height=6329 ...
01/18/22 23:09:27 CheckDiskBlocks() at height=5329 ...
01/18/22 23:09:27 CheckDiskBlocks() at height=4329 ...
01/18/22 23:09:27 CheckDiskBlocks() at height=3329 ...
01/18/22 23:09:27 CheckDiskBlocks() at height=2329 ...
01/18/22 23:09:27 CheckDiskBlocks() at height=1329 ...
01/18/22 23:09:27 CheckDiskBlocks() at height=329 ...
01/18/22 23:09:27 block index 8249728ms
01/18/22 23:09:27 Loading wallet...

Is it something like, checkblocks=0 checks from genesis and checkblocks=600000 checks starting 600k blocks deep ?

More or less. Technically they did the 'from genesis' part as (brace yourself...)

if (nCheckDepth <= 0)
    nCheckDepth = 1000000000; // suffices until the year 19000

and it works from the most recent block backwards (and still has the off-by-one I noted).

Come to think of it, for the default I'm liking my original 144 if only to emphasize that it's our decision and they aren't the reference or basis for anything. Only reason I checked was so that we don't end up loading the same option with such different behavior that it creates pointless confusion for people switching.

Nitpick perhaps, but checking from genesis is magic-free; and it's a valuable tool to have for when you're dubious of the whole data set rather than just recent parts, as indeed I was with this flaky machine.

Ok, and I agree that it's valuable.

Does it merely come to mind, or do you mean something more by it? I see what's depicted there as a social failure, a rejection of the actual hierarchy with a hallucinated self-serving alt-hierarchy, quite in the "open sores" tradition where if you don't personally code then you're presumed not to have something to say on the subject.

Well, you did say, "What extra information does the user have that would allow him to make a better decision here than the developer?" The point is, there could be A LOT of extra information an active and technically informed operator who doesn't code for his bread has that developer doesn't.

Basically, that we can't figure out a correct choice up front isn't our failing but does indicate an immature project for not having seen enough useful users yet.

So that tells me the adding the optionality is worth it.

There was more packed in there than just the choice of number though

Ah, right. So, they did add in the optionality ? Is it something like, checkblocks=0 checks from genesis and checkblocks=600000 checks starting 600k blocks deep ?

but only having 2 magic number options, a recent check and a check from genesis, also carries a cost and the latter will only grow as the chain lengthens

Nitpick perhaps, but checking from genesis is magic-free; and it's a valuable tool to have for when you're dubious of the whole data set rather than just recent parts, as indeed I was with this flaky machine.

How long is checkblocks taking at present ?

It took 7.4 hours for 683071 blocks.

It seems to me that the cost of adding the optionality goes under the cost of inheriting shitcode account in the ledger.

I could see it.

Re better decision than the developer, this quote comes to mind.

Does it merely come to mind, or do you mean something more by it? I see what's depicted there as a social failure, a rejection of the actual hierarchy with a hallucinated self-serving alt-hierarchy, quite in the "open sores" tradition where if you don't personally code then you're presumed not to have something to say on the subject.

Possibly closer to the point here are the discussions of optionality in the MP-WP context, most prominently here. Basically, that we can't figure out a correct choice up front isn't our failing but does indicate an immature project for not having seen enough useful users yet.

the default is 288. Perhaps that's the way to go.

There was more packed in there than just the choice of number though - for instance the 0 meaning "check all", and the break in meaning e.g. where -checkblocks=1 previously meant "all" and now means "minimum". I don't think it's a problem tbh, especially since no prior mention in the help. Just want to confirm we're on the same page tho.

Well, if there's a case to be made against it I'm certainly open to hearing, though I can't imagine what it would be in light of the consequences illustrated here, and I wasn't asking for one.

Alright, I don't have a case against.

Indeed I'd say instead that the "every 500 blocks" was a (defective) software solution for a hardware performance problem.

Yeah, I can see it.

Possible future events have the pesky property of not being constrained by past observations, but I don't think that's a concern here.

True.

The question is "how many blocks deep might some data have gotten corrupted without our noticing the first time for whatever reason"; my argument for keeping it something greater than one is the unknown of what those reasons might be.

Right, I follow that.

Alright, I wasn't aware of the implementation details on checkblocks, thanks for clarifying. I agree that adding optionality isn't free, but only having 2 magic number options, a recent check and a check from genesis, also carries a cost and the latter will only grow as the chain lengthens. How long is checkblocks taking at present ? It seems to me that the cost of adding the optionality goes under the cost of inheriting shitcode account in the ledger.

In this case it seems possibly more of a deflection of responsibility. What extra information does the user have that would allow him to make a better decision here than the developer? "His level of tolerance for this narrow species of unknown risks" I suppose. There's some kind of balancing act here.

Re better decision than the developer, this quote comes to mind.

The questions are, is boxing the operator into check recent or check from genesis a legitmate responsibility of the developer ? Or is it the responsibility of the developer to slowly chip away at removing magic numbers from the code ?

That's how I'm seeing it at least.

the default is 288. Perhaps that's the way to go.

Ok.