Checkpoints Enlightment

[Viriatto]

Greetings,

I've been messing around with "C" coding from different coin systems, trying to understand all the logic behind it.
There is a subject that im not yet clear to understand, at checkpoints.cpp:

        ( 15000, uint256("0x00000082cab82d04354692fac3b83d19cbe3c3ab4b73610d0e73397545eb012e"))
        ( 30000, uint256("0x0000000af2f6e71951d6e8befbd43a3dac36681b5095cb822b5c9c8de626e371"))
        ( 45000, uint256("0x00000000591110a1411cf37739cde0c558c0c070aa38686d89b2e70fe39b654f"))
        ( 60000, uint256("0x000000000c067c5df98a8285ff045c3ffee46eb64b248bc6622f6bdceb8558be"))
        ( 75000, uint256("0x000000004ab2d277c8a056f55f32efa515a9931cb0404d60d0efc4f573412e66"))
        ( 90000, uint256("0x000000000cfe2ec9d27b784c2627c3864d26e5829cc5b18b4eff37d863ed0675"))
        ( 105000, uint256("0x00000000b0480b6a15fee32ee47d4b30dc82dc44ab680f1debb2ce2b13f73aab"))
        ( 120000, uint256("0x00000000d843c5c818620d00c9352e0cc3bbf7fdb9d69093795fbfffff13c92a"))
        ( 135000, uint256("0x0000000292cb16d5935e015a786d33f3228da23d92dfeb6ddff7249a3227f956"))
        ( 150000, uint256("0x000000035d01ee7f75032c0293a7e6b1217d447fe3e000ede7911cb0520c60c7"))
        ( 165000, uint256("0x00000001e790d65de9541af419465338220de69e3ffcbda427af2fc94741d321"))

What is the point of adding checkpoints? can someone explain me the theory?

Cheers

[jackjack]

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

[TierNolan]

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

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.

[Viriatto]

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?)

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...

[maaku]

No, it has nothing to do with transaction fees. What are you talking about?

[TierNolan]

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

Code:

    // 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.

[gmaxwell]

I wish people would stop asking this question, it gets a lot of bad and incomplete answers — as it is here.

The most actually-useful consequence of these things is avoiding some trivial DOS attacks. For example, someone produces an alternative chain of 1MB diff 1 blocks, you'd normally save them just in case that chain ultimately got ahead. ... and thus run everyone out of disk space.  This can be avoided in other ways, but in the reference software checkpoints (and some rules which calculate how high in diff a block must be to ever be part of a longer chain) are how this is currently avoided.

Please search the forum, this has been asked many many times before.