Closed mvandeberg closed 3 years ago
Some notes:
(1) The checkpoint check described in this issue is a check that only occurs when connecting to a node. It is still possible to receive and apply blocks that fail the checkpoint, for example if Alice syncs to Bob, who hasn't yet gotten to the checkpoint, but Bob isn't using the checkpoint and is himself syncing to Charlie, who isn't using it either. Then Charlie might have a block that will fail the checkpoint, give it to Bob who won't fail it either, and Bob will give it to Alice since Alice only checked Bob against the checkpoint when Alice connected to Bob, and Bob received the block after that.
(2) The checkpoint check is only performed against the primary fork. Therefore, we may still connect to Bob if Bob has at some point heard about blocks that fail the checkpoint. We only disconnect from Bob if those checkpoint-failing blocks are on Bob's primary fork.
(3) We determine a peer's primary fork by issuing GetHeadBlockRequest
.
The ticket and implementation only describes applying checkpoints as part of the handshake. So I'm going to edit the ticket title to better represent its actual scope.
We'll have to reimplement this after the P2P rearchitecture.
As a node operator, I want to specify a checkpoint to guarantee my node syncs to a specific fork.
The checkpoint needs to consist of a block height and a block id.
Upon connecting to a new peer for sync, we ask the peer what their block id is at the checkpoint height. If they respond with the expected ID, we sync to them. If they respond with a different ID, we disconnect to them from sync and add them to the local blacklist.