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?)
The checkpoints are set by the developers. In the future, they may not have the power to do this (if there are many alternative clients).
All of the client dev teams getting together could still agree on a block being check-pointed and then add the block to their clients.
The policy of the reference client dev team (at least according to the code) is
// What makes a good checkpoint block?
// + Is surrounded by blocks with reasonable timestamps
// (no blocks before with a timestamp after, none after with
// timestamp before)
// + Contains no strange transactions
The latest checkpoint was added on 20th August for block 250000. Block 250000 was added on the 3rd of August, so the block was around 17 days old.
At mid-day on the 20th August, the chain was at block 253194, so it was more than 3000 blocks old. In addition, that is for dev build. By the time the block is actually released, the checkpoint will be much older.
If there was a 3k+ reversal, then the dev team could change it.
Great, so this means we can setup new transaction fee's just by defining a checkpoint on the new TX block?
No, the client always checks all the blocks right from the start. If a block tries to create inflation (pays to much in the coinbase), then it will be rejected.
The only thing checkpoints do is allow the client to skip signature verification. It just assumed the digital signatures are correct, but it still checks everything else. This is because the signatures are really slow to verify.