10 sats \ 2 replies \ @nerd2ninja 26 Apr 2023
They try to avoid calling them checkpoints but yes, and you can turn off assume valid (I did) and verify the full chain from block 1. It takes like a week but if you have a machine dedicated to your node, why not?
reply
0 sats \ 1 reply \ @0260378aef 26 Apr 2023
The issue is a bit deeper than that.
The problem is that without checkpoints, crudely, a completely new node has no way to distinguish a bunch of very, very deep blocks in a very long fork, that doesn't reach very high difficulty (so, easy for an attacker to create) but, from its branch point is still valid. So it has to be "scanned" along, even though the node will later find a far higher work chain (the current/'real' one).
Headers first was a big change to that, and was added years ago, so at least you're not scanning entire blocks during this process. But apparently there could still be an issue (maybe? I have no idea) even there, with having to scan a huge list of block headers.
So having checkpoints as anti-DOS for new nodes doing IBD kinda makes sense, while at the same time, it's pretty important that we have the right security model - which does not include someone arbitrarily hardcoding the 'correct' blockchain!
reply
0 sats \ 0 replies \ @nerd2ninja 27 Apr 2023
Sounds like an issue of time preference. I personally prefer to not have checkpoints, doesn't matter if it takes weeks to go through multiple chains to find the one with the most work. At the same time, if a client with a checkpoint comes out, we got many node runners who don't change clients (and yes I'm calling it changing clients rather than "upgrade") for the first few years that client is out.
As we know, a new client that disagrees with old clients gets forked off and everybody is going to know about it.
So you know, a lot of nuance, but I personally run the more intensive options.
reply