Quote from: jackjack on August 25, 2013, 08:34:50 PM

Imagine a guy is mining a second blockchain since block 2
Now imagine he manages to make it longer (by mining or by finding a flaw in the mining process) that the one we currently see and he releases it
Result: all transactions are reverted and the only one to have any bitcoins since block 2 is him

By adding a checkpoint at block n, you force your client to refuse chains if the hash for their block n is not the one of the checkpoint, so the guy can't revert the blocks older than n

Best imaginary explanation, then it would make sense to have a dynamic callback filling this checkpoints automatically by a consentual wallet analysis?
There must be a way of having all the wallets posting/confirming same "N" from time to time, or block to block (every 1500 blocks for eg?)

Quote from: TierNolan on August 25, 2013, 09:27:34 PM

A second benefit is that you can skip signature verification. Checking that every transaction is signed properly is the major CPU load for downloading the blockchain.

The reference client still checks each block to make sure no double spends happened and that the minting rewards were valid, but it doesn't check that the transactions were properly signed.

Once it hits the last check-pointed block, then signature verification is switched on. This speeds up downloading the chain. It turned out that CPU load when checking the signatures was the bottleneck. Even though the chain is many GB long, network speeds were fast enough so that the CPU was the bottleneck.

The older your checkpoint is, the more signatures you have to check "manually".

It is possible to turn off checkpoints, if you want to fully verify the chain yourself. I don't know if they have a way to keep checkpoints but still check all signatures anyway.

Great, so this means we can setup new transaction fee's just by defining a checkpoint on the new TX block?

Lovely, thank you both for the light...