What I don't understand about writing bitcoin software, that you do?
You have this patronizing attitude all the time,
I suggest you review this thread before you continue to complain about
patronizing.
When someone says "new nodes don't need the data anyways." and you respond "Indeed.", it's a little hard to not get the impression that you actually might have no clue what the Bitcoin security model is, even when you do follow it up by, "But you know, they are very busy now with "tackling the low lying fruit" - whatever useless feature it is"— suggesting that you're just agreeing with a confused complaint and trivializing the actual nuance and complexity of the issue for the sake accusing people actually doing work on the reference client of working on useless things.
One of these explanations has lower entropy than the other, I suppose. But the trolls in the mining subforum seem to have dulled my Occam's razor. Feel free to provide your own alternative psychoanalysis. In the meantime, I'm stuck providing the detailed technical discussion that you declined to provide, whatever your reasons.
Are you saying that I don't understand how the concept of checkpoints reduces bitcoin's security model?
You were suggesting that historic data would be made unavailable and non-validated. That isn't what checkpoints do.
Maybe you don't understand that if the only way for a bitcoin software to work is by validating a chain up to a checkpoint that is fixed inside the very same code that validates the chain - then validating the chain up to that point is just a big waste of time, bandwidth, CPU and storage.
That simply isn't correct. If the history is validated then it cannot be forged and replaced with a false history which invents additional coins out of thin air. Without validation any of this cheating is undetectable. People often make crazy claims like "Satoshi embedded a billion of his own bitcoin into the system!", it's excellent that we can point out that every copy of the software verifies that this isn't so, and that any user with the source can audit it to confirm that it does. The fidelity of Bitcoin's lifetime conformance to the understood rules is check-able trivially by anyone (or by their designees). Checkpoints don't harm this, but checkpoints without the possibility of validation would destroy it.
[And here I'm writing for the sake of people who randomly find this thread in searches, I don't expect you to learn anything here you don't know:]
Checkpoints serve three main purposes:
(1) Prevents DOS attacks against node synchronization. Under the original synchronization behavior an attacker can send a node hundreds of gigabytes of difficulty 1 blocks (which thanks to FPGAs and asics can be very cheaply produced). This difficulty 1 chain might— once synced far enough in _theory_ eventually have more sum diff than the real chain, so a checkpointless node can be forced to evaluate it. Checkpoints kill this attack dead, though they aren't the only way to kill it, they're a simple and reliable one.
(2) Prevents isolation attacks against newly started nodes. People most often talk about the Bitcoin security assumption being that most-hashpower-is-honest, but equally important is that "information is hard to stifle" assumption: Bitcoin is not secure if a network attacker can isolate you from the honest network. A newly started node might instead be intercepted by a local network attacker which feeds it a low difficulty fantasy hashchain and tricks it into accepting payments on this alternative network, even though the attacker only has a single small GPU miner with about 0.0000001% of the network hashrate. Checkpoints mean that a user which was reliably able to obtain the software (E.g. via another network or PKI/WOT authenticated signatures) will not be tricked by an attacker which has not put in an enormous amount of energy creating a simulated network.
(3) Simplifies discussions about the risk of mass-chain-rewrites. Many new users in the past fixated on the risk of 'doomsday rewrites' of the chain. There is no particular reason to be concerned about these: Under any situation where these are possible the system is otherwise doomed but people do anyways, and understanding why this not a likely attack requires sitting down and multiplying out the costs. With checkpoints this concern is thoroughly moot. In particular, a new argument against doomsday rewrites arises: any would-be rewriter takes a risk that a checkpoint is adopted while he is in the process of preparing his rewrite in secret and losing all his work. The compromise, of course, is that it creates a risk of consensus failure if ever a checkpoint is ambiguously set. But the introduction of checkpoints is transparent and they are never set close to current time or controversially, so no practical parties are worried about this.
when you want to start disabling things in the source code
If you do not like checkpoints, the reference software has a supported and advertised option to disable them -checkpoints=0, you don't need to modify the source or delete them or anything. I, and a number of other folks run supervised nodes in this state, and it works fine— though do check to make sure you're not isolated.
Checkpoints are needed - for the very reasons that they were put in, in the first place.
They really aren't. We have a number of other alternatives.
I'd personally like to remove the checkpoints: Difficulty checkpointing and headers-first synchronization are superior replacements, though they are slightly more complicated to implement. They are superior because they provide protection even far away from the checkpoints and when they are not been recently updated. Eliminating the rigid checkpoints also would allow for some better performance optimizations.
The loss of (3) would be unfortunate but in recent times the community of users is seems to be less worried about rewrites and the benefit would be the elimination of researchers who see 'checkpoints' and come to a totally erroneous conclusion about the security model.
It does raise the question of how to find the longest chain in a hostile environment.
Sync headers first, this is only 80 bytes of data per header. Set a minimum difficulty of 100k past the first point where that was achieved (which can easily be maintained by a dozen ASICs now, so there should be no prospect of a viable Bitcoin falling below that ever again) to eliminate cheap header flooding. Add a minimum sum difficulty hint to prevent isolation from being anything but a DOS unless it is also a high hashpower attack. Even better robusness to header spamming could come from
reverse header syncing but it really wouldn't be important.
