56

Bitcoin Cash: All about checkpoints

 5 years ago
source link: https://www.tuicool.com/articles/hit/jmqEjqq
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

A decisive opening battle has been won by the defenders of Bitcoin Cash in Craig Wright's war to hostile takeover the chain. The chain is now permanently split despite Craig's repeated declarations that "There will be no split!" and now SV supporters are crying foul because the Bitcoin Cash developers have added a checkpoint into the code to prevent Craig from wiping out a day's worth of blocks, causing people to lose millions of dollars, and undoing the chain split. In this article I will thoroughly explain what checkpoints are and why BSV supporters are wrong, yet again, about how the protocol works.

What are checkpoints?

A checkpoint is a line added to the code that prevents the software from reorganizing the blockchain below the checkpointed block. In the event that an attacker (such as Craig Wright) were to try to 51% attack and wipe out all blocks and transactions that happened on Bitcoin Cash over the past day, the software will not let him do it.

Are checkpoints anti-Bitcoin?

BSV supporters are claiming that checkpoints are a violation of the Bitcoin protocol and thus make the ABC side of the chain somehow "not Bitcoin" or "opposed to Satoshi's design". The fact of the matter is checkpoints have been part of the Bitcoin codebase since 2010 WHEN SATOSHI ADDED THEM! Here's what he wrote about it:

z2eYbuF.png!web https://i.imgur.com/zpToBW0.png

Notice his reasoning for doing so. "The security safeguard makes it so even if someone does have more than 50% of the network's CPU power, they can't go back and redo the block chain before yesterday". This is EXACTLY the same as what the Bitcoin Cash developers did and for the exact same reason. Satoshi goes on to say that "Once the software has settled on what the widely accepted block chain is, there's no point in leaving open the unwanted non-zero possibility of a revision months later." His reasoning is pretty sound. You can't have a sound monetary system that is subject to randomly having days, weeks, or months worth of transactions undone. At this point there is 100% consensus on the state of the blockchain as of yesterday. The consensus forming process is over and all nodes agree that block 556767 (0000000000000000004626ff6e3b936941d341c5932ece4357eeccac44e6d56c) is part of the chain. Why allow it to be wiped out? The BSV supporters are literally wining about the fact that the checkpoint prevents Craig Wright from causing people to lose millions of dollars. This should tell you something about the ethics of people who are supporting BSV. Further. Not only was Satoshi the one who added checkpoints into the code... the were never removed! Here's the l i ne in Bitcoin SV's own codebase containing checkpoints.

FRFRZ3Z.png!web https://i.imgur.com/52Krues.png

The checkpoints also exist in the Bitcoin Core codebase though the Core developers have stopped adding new ones. Thus since at least 2010 no implementation of Bitcoin has allowed unlimited length reorgs back to the genesis block. If BSV supporters want to claim that being able to reorg back to the genesis block is a requirement for something to be "bitcoin", well then I guess nobody has been using Bitcoin all this time.

Do checkpoints make Bitcoin Centralized?

Checkpoints do not materially change the security properties of the software. All Bitcoin full node implementations are shipped with the genesis block hardcoded into the software. If, by chance, the developers hardcoded the wrong genesis block you node could sync onto an invalid chain and thus you could be tricked into accepting fake bitcoins as payment. If you want be sure that you bootstrapped onto the correct chain you have two choices: 1) Download the source code. Manually verify the genesis block against a known good source*. Then manually compile the software. 2) Trust that the developers hardcoded the correct genesis block. * Finding a known good copy of the genesis block is not as easy as it sounds as you need to make sure the source you're downloading it from is trust worthy (and can you really be sure?) and you have to make sure you aren't man-in-the-middle-attacked as you do so. But those are your two options. A checkpoint could be thought of as simply rolling the genesis block forward. As someone who wants to make sure they bootstrapped onto the correct chain your options are still: 1) Download the source code. Manually verify the checkpoint block against a known good source*. Then manually compile the software. 2) Trust that the developers hardcoded the correct checkpoint. This is nearly identical security. So, no, checkpointing after the fork does not make Bitcoin Cash "centralized".

Why don't we checkpoint more frequently then?

The downside to checkpointing is introduces a non-zero risk of consensus failure. Imagine for instance that new software is released that checkpoints a block a week ago. Some nodes on the network upgrade to the new software and other nodes do not. If a reorg were to happen that would otherwise wipe out over a weeks worth of blocks, the upgraded nodes would reject the reorg but the non-upgraded nodes would not. Essentially nodes will have fallen out of consensus with each other. The Bitcoin Core developers have stopped adding checkpoints for this reason. If a long reorg were to happen (say weeks or months) their software would technically continue to function as written and everyone on the network would reorg on to the new chain. But while the software would continue to function technically , it obviously would not be functioning economically . A deep reorg like that would be catastrophic for a system that is supposed to be sound money. If that ever happened, consensus failure is the least of your worries as the value of the chain would likely crash close to zero. So checkpoints are are tradeoff between the risk of a catastrophic reorg and consensus failure. In that instance I'm personally more likely to come down on the side of consensus failure because at least that doesn't destroy the whole system and a consensus failure can possibly be rectified simply by telling people with old software to update.

Bitcoin Cash has checkpointed at each hardfork

When the fork happened Craig and Calvin were mining BSV with about 3.5 exahashes. As of now they are mining with around 5 exahashes. Where did this extra 1.5 exahash come from and where was it when the chain split started? The most likely explanation is they were trying to 51% attack Bitcoin Cash by mining a hidden chain and then had to abandon the hidden chain once they learned of the checkpoint. But this is sheer incompetence! Bitcoin Cash has checkpointed after each of it's three previous hardforks. If they had even passing familiarly with the development practices of the network they are trying to take over or the software that they are now trying to manage, they would have known this! Here are the checkpoints in the code for the three previous hardforks:

bqUJnuU.png!web https://i.imgur.com/tlxvImw.png

Finally, I stand firmly by my belief that the vast majority (if not all) of the loud voices on the BSV side of the debate have virtually no technical understanding whatsoever. That they would all of a sudden be shocked and offended by a practice that has been going on since 2010 when Satoshi started it shows you that they have no idea how the protocol works, how the software works, and do not have anywhere near the depth of knowledge of these subjects that the Bitcoin Cash side has. Yet they desire to take over and run Bitcoin. You decide who's on the right side of this one.

The future of checkpoints

Checkpointing will likely become more important as Bitcoin Cash scales and the chain becomes larger. At gigabyte blocks the blockchain will be too unwieldy to store the entire thing on a typical computer and syncing from genesis would take an ungodly amount of time. In bchd we are going to be implementing a fast sync mode that will allow you to sync a node form a checkpoint in about a half hour. Currently the checkpoints look like this in the code: { Height: 556767, BlockHash: "0000000000000000004626ff6e3b936941d341c5932ece4357eeccac44e6d56c" } We plan to extend the checkpoints to the following: { Height: 556767, BlockHash: "0000000000000000004626ff6e3b936941d341c5932ece4357eeccac44e6d56c", UtxoSetHash: "f30a765ad6c5777e82eb2b64cfa53cdbb08d435546dd351880c13691867290b4", UtxoSources: [ "http://localhost:8080/ipfs/QmQLXHs7K98JNQdWrBB2cQLJahPhmupbDjRuH1b9ibmwVa", " https://bchd.cash/utxoset/f30a765ad6c5777e82eb2b64cfa53cdbb08d435546dd351880c13691867290b4 " ] } If the node is run with the --fastsync option it will try to download the utxo set first from IPFS (if you have the IPFS daemon running locally) and fall back to downloading from our server. It will then calculate the hash of what it downloaded and compare it to the hash in the checkpoint. There will be a tool available which will allow anyone with a fully synced node to verify that the hash of the utxo set that we put in the checkpoint is correct. You should be able to get a node up and running in a under a half hour. Expect this to land in bchd by the end of the year.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK