+1
headers first syncing will remove the need for checkpoints.
Topic: Re: What are checkpoints in bitcoin code? - page 2. (Read 2839 times)
Far better to just get rid of them: Headers first makes most reasons obsolete. The circus above doesn't really help, since it's using the chain itself, which of course checkpoints distort the selection of, so it's just circular.
It seems pretty clear that checkpointing by the devs introduces an avenue for corruption/compromise of the chain. But checkpoints are certainly a reasonable approach to preventing forms of DoS and potentially even accelerating new nodes catching up with the chain.
What if we worked towards a check-pointing process based on proof-of-work? It could work something like this:
- A checkpoint is proposed on bitcointalk or reddit or wherever.
- Check-pointing becomes an on-chain transaction, where the block-to-be-checkpointed's hash is included in a tx. It could be earmarked by doing something silly like spending a millibit from the coinbase reward.
- A checkpoint is accepted as valid if it is included in some X of Y blocks in a row in this manner. X could be something like 70 and Y 80, say (to be totally arbitrary). Then the checkpointing processes requires consensus from the whole network, but is not spoiled if a few miners/pools decide they want to be adversarial. If large pools are staunchly anti-checkpoints, then arguably that's the network's decision to make.
Once a checkpoint is conceded on the blockchain, the devs can add it to the source code, and the client can verify that it is indeed a valid checkpoint by finding the first block it is checkpointed in and verifiying the same hash exists in X of Y consecutive blocks. I believe this can be done without a fork (presuming coinbase rewards can be used as inputs within the same block, else we need another way to earmark the special checkpoint txa, but I imagine this shouldn't be too difficult).
Thoughts?
What if we worked towards a check-pointing process based on proof-of-work? It could work something like this:
- A checkpoint is proposed on bitcointalk or reddit or wherever.
- Check-pointing becomes an on-chain transaction, where the block-to-be-checkpointed's hash is included in a tx. It could be earmarked by doing something silly like spending a millibit from the coinbase reward.
- A checkpoint is accepted as valid if it is included in some X of Y blocks in a row in this manner. X could be something like 70 and Y 80, say (to be totally arbitrary). Then the checkpointing processes requires consensus from the whole network, but is not spoiled if a few miners/pools decide they want to be adversarial. If large pools are staunchly anti-checkpoints, then arguably that's the network's decision to make.
Once a checkpoint is conceded on the blockchain, the devs can add it to the source code, and the client can verify that it is indeed a valid checkpoint by finding the first block it is checkpointed in and verifiying the same hash exists in X of Y consecutive blocks. I believe this can be done without a fork (presuming coinbase rewards can be used as inputs within the same block, else we need another way to earmark the special checkpoint txa, but I imagine this shouldn't be too difficult).
Thoughts?
Jump to: