Quote from: TheFascistMind on October 05, 2014, 12:28:58 AM

Quote from: smooth on October 05, 2014, 12:23:56 AM

Quote from: TheFascistMind on October 05, 2014, 12:17:34 AM

Quote from: smooth on October 04, 2014, 10:05:05 PM

Quote from: crypto_zoidberg on October 04, 2014, 09:51:14 PM

Anyway, can you say at least one real argument against removing RS under checkpoints ?

It isn't possible to independently verify the chain. This significantly elevates the trust model for checkpoints from choosing among valid chains to trusting that the chain below the checkpoint was valid before being trimmed. Again, tradeoffs....

The chain is verified by the fact that the block hashes are immutable. An attacker can't change the transaction data by even 1 bit and get congruence with the block hash history.

The block hashes don't include the ring sigs. That's why the ring sigs can be removed without breaking the block hashes.

There is no assurance that there were ever valid ring sigs there, unless you were around to see it.

Afaik, the list of inputs and outputs are in the block hash. Only the proof that those inputs were signed for is discarded. No one can change 1 bit of those inputs without violating the immutable block hashes.

You don't need to have been around, because the longest chain rule assures you are looking at the consensus.

Zoid is correct.

See edit above. You are trusting that the code that constructed that chain (i.e. accepted those inputs and outputs) worked correctly. That does not need to be the same code you are using today. You can't verify it.

Personally (and I'm pretty sure tacotime agrees) I believe that SPV-style approaches are far better, where it is possible to verify as much of the chain as you want, but not necessary to verify all of it to function, and fully verifying nodes still exist. Yes I am aware that an exact mapping of Bitcoin SPV does not apply, that's why I said SPV-style, not SPV.