Countertake: I think checkpoints every six months are fine. A lot of technical complexity was added to initial header download to avoid checkpoints, but the reality is that if we have a reorg deeper than 6 months, the whole system is worthless. If you just own the checkpoints,
8 years ago I explained Bitcoin's security model and spent a lot of time clarifying the purpose of hard coded block checkpoints. At long last, the next release of Bitcoin Core will completely remove them. https://t.co/b6G4m6kWLQ
5
1
30
Replies
@jamesob Checkpoints don't avoid DoS issues during IBD. Before you've received a checkpointed header you'd accept any low work fork prior to it.
1
0
0
@dergoegge The complicated double-retrieval header download scheme was implemented specifically to avoid adding checkpoints:
1
0
1
@dergoegge I was in the initial conversations; the impetus was "it's no reasonably cost effective to forge a header that's higher PoW than the last checkpoint, so instead of adding a checkpoint let's do [complicated change above]," but correct me if I'm misremembering.
2
0
0
@jamesob @dergoegge I think it was two different things. Historically there was only checkpoints, and the optimization to not validate input scripts before them. It was then split into assumevalid vs checkpoints. Then checkpoints's impact on consensus was weakened by only rejecting alternate
2
0
1
@darosior @dergoegge I don't understand what your point is with this - assumevalid came well before the push to remove checkpoints a few years ago, which largely resulted from the realization that it was now costly-but-possible to forge a PoW higher than the latest checkpoint.
1
0
0
@jamesob @dergoegge Niklas pointed out that we can still be DoS'd until we have actually seen the chain with the checkpointed header. You said yes that was part of the headersync work. I said no this was done years before. (But you are right this could be reverted of course.)
1
0
0
@darosior @jamesob @dergoegge Idk if this will help in the conversation, but Pieter gave a great explanation about it here:
1
1
0
@darosior @sliv3r__ @dergoegge lol, this is a crazy design choice. It is not at all realistic, even though it satisfies mathbrain. If you simply grant "no, we are not going to allow reorgs from genesis," you can avoid a ton of complexity as mentioned elsewhere
1
0
0
@jamesob @sliv3r__ @dergoegge Sorry what? If a node refuses to reorg from genesis then it trusts its first peer to serve it the correct chain or it's stuck forever.. This is not realistic.
1
0
0