Post
Topic
Board Development & Technical Discussion
Re: What are checkpoints in bitcoin code?
by
gmaxwell
on 02/11/2014, 02:51:29 UTC
This is where I'm losing you. Yes there may be a checkpoint, but highest total difficulty still wins out. If the highest difficulty chain conflicts with a check-pointed one, surely the client should go with the higher difficulty one, as you say
Quote
chain will simply be unwound and replaced, so giving it that extra data is harmless, once the honest network is observed its like the node never saw the forgery
. The checkpoint is merely a mechanism to avoid verifying very old txs. But if I see a competing chain with higher difficulty, I ought to go with that one, whether it has a checkpoint or not.
What you're describing is not a checkpoint then. A checkpoint forces the identity of the selected chain, regardless of it has the most work or not. So that would be the point of departure.

What is the point of the rest of the complexity in what you're discussing then? The "propose", "earmark" milibits? etc. (and no, newly generated coins cannot be spent for 100 blocks). The blockchain itself is already the measurement of its history.  If you're willing to trust the data in the blockchain, you just can no extra information is required. (Though if you're willing to adopt that reduced security model, why are you not going all the way and using SPV (see section 8 of bitcoin.pdf)?  Presumably you're aware that you still need to transfer the data and process it to be able to verify further blocks, right?

[If you're talking about small numbers of blocks like that, what you're proposing would be a considerable reduction in the security model, since the reward for a miner to hop ahead of the network would basically be unbounded, so that the incentives arguments on behaviour are much weaker. Weaker has it's place, but thats what SPV already accomplishes.]