29

The checkpoints are hard coded into the standard client. The concept is, that the standard client will accept all transactions up to the checkpoint as valid and irreversible. If anyone tries to fork the blockchain starting from a block before the checkpoint, the client will not accept the fork. This makes those blocks "set in stone".


14

The issue is that you assume a majority attack is an attack that can be prevented. It is not. It is a fundamental breakdown of the security assumptions. Proof of work (PoW)'s assumption is that the majority of the hashrate will cooperate and converge on a single chain, because it is most financially advantageous thing to do. When that is no longer the case, ...


8

As long as both competing chain-tips are adhering to the same rules, the chain with the most aggregate difficulty ("heavier") will win, regardless of height. Nodes performing the initial sync would automatically end up on the heavier chain by comparing the aggregate difficulty of the chain-tips offered by their peers due to headers-first synchronization. ...


7

Checkpoints serve two purposes: They hardcode a historic part of the chain They allow us to disable a check (expensive signature checking) in that historic part. I personally dislike the first part, as it requires users to trust the software they're downloading contains the right checkpoints. Of course, they're already trusting the code anyway in much more ...


7

I wanted to start mining bitcoin from the genesis block I'm pretty sure regtest will let you do that. why wouldn't the peer just let me mine on my own chain and not broadcast my results to anybody? Because that would be pointless. You're not confirming transactions, and you won't get rewarded for your mining. Your chain will probably be overwritten the ...


5

You can find the list in bitcoin source code. These are the current checkpoints (from git revision c091b99): checkpointData = (CCheckpointData) { { { 11111, uint256S("0x0000000069e244f73d78e8fd29ba2fd2ed618bd6fa2ee92559f542fdb26e7c1d")}, { 33333, uint256S("0x000000002dd5588a74784eaa7ab0507a18ad16a236e7b1ce69f00d7ddfb5d0a6"...


3

From this discussion: How to create a checkpoint file Run mvn exec:java -Dexec.mainClass=com.google.bitcoin.tools.BuildCheckpoints in the tools/ directory from the bitcoinj repository. BuildCheckpoints expects you to have a fully synced local Bitcoin-Qt/bitcoind instance running.


3

Checkpoints are features of certain clients, not inherent to the blockchain itself. So, if an attacker did re-write the chain all the way back to a popular checkpoint, he could maybe get the network to disagree. Some would go with the 'chain with most work wins' approach, and some would go with the 'chain that meets my checkpoints with the most work' rule. ...


3

The short answer is no, because you can run Bitcoin Core with -nocheckpoints, and different versions may have different checkpoints. The long answer is that it doesn't matter. If checkpoints ever actually prevent a reorganization of a fully synchronized client, it means that the assumptions on which Bitcoin's security relies (collusion of a majority of ...


3

Update on this as of time of writing, just to clarify more specifically upon the other answer: dependence on checkpoints in the security model has been significantly reduced, they are only used in one very specific case now. That case is just to ignore forks from the chain early on, before the most recently seen checkpoint. When a node has seen a block it ...


2

At least in Bitcoin Core, none. Checkpoints are legacy and will likely be removed at some point. Checkpoints were originally introduced as a way to enable skipping of signatures in the historical chain, without being vulnerable to accepting an alternate history. That role has now been overtaken by the assumevalid concept (a block hash that is known to be ...


2

Centralized checkpoints is a mechanism whereby nodes trust a certain hardcoded key to make new checkpoints. This means that in case of a fork, the key owner can make the network choose any branch he wants, even the one which is shorter. If this key is compromised, an attacker can use it to mount an equivalent to 51% attack with any hash rate. This, together ...


2

Depending on what you meant to ask, the answer is one of the following: If you run a Bitcoin-qt fork which is incompatible with the rest of the network, you're running a separate currency which has no value (because no one else accepts it). If you ignore blocks and forge historic timestamps to create a branch with more blocks of low difficulty, it will not ...


2

You are correct that any client which sees two different forks can easily determine which one is longer. But consider the following possibilities: The node might never see the longer fork. This can happen in case of a Sibyl attack, where the attacker has control over the victim's Internet connection and arranges that the victim only connects to evil nodes....


2

You can generate several blocks and put (block_height, block_hash) pairs into the following field. Or just delete all of the checkingpoints : ) static Checkpoints::MapCheckpoints mapCheckpoints = boost::assign::map_list_of ( BLOCK_HEIGHT, uint256S("0xBLOCK_HASH")); static const Checkpoints::CCheckpointData data = { &...


2

If ‘block finalization’ is needed, then your chain is broken. I say this because PoW is the method by which the Bitcoin network maintains consensus, and so the only reason we may introduce a ‘block finalization’ is if we worry that PoW will not be able to accomplish it’s job. If PoW cannot accomplish its job, then the system is already broken. It really is ...


1

A Checkpoint is the header hash permitted at a given height, thereby hardcoding the chain that the validating node must follow. If a node follows an alternative chain branch which reaches the same height, this branch can now be identified as such and rejected. This was initially designed to protect a node from following an alternative long branch, especially ...


1

See What are checkpoints? for some clarification. To quote ThePiachu's answer: The checkpoints are hard coded into the standard client. The concept is, that the standard client will accept all transactions up to the checkpoint as valid and irreversible. If anyone tries to fork the blockchain starting from a block before the checkpoint, the client will not ...


1

AFAIK they are not crucial at all. They are simply one more safety check, but without them the blockchain should work well enough anyway...


1

There are two things : Why are checkpoints needed in the first place, Why do the checkpointed blocks need to adhere to the standards you are quoting (which is your question) I don't think checkpoints are required at all or useful in any way, there has been some debate around this, the fact remains that checkpoints are still present in the Satoshi ...


Only top voted, non community-wiki answers of a minimum length are eligible