who makes the checkpoints?
The bitcoin core devsbut if you disagree with any checkpoint they add, just don't upgrade your node and you will be fine.
Topic: What are checkpoints in bitcoin code? - page 5. (Read 14791 times)
but if you disagree with any checkpoint they add, just don't upgrade your node and you will be fine.
who makes the checkpoints?
The bitcoin core devs
who makes the checkpoints?
The bitcoin core devs
who makes the checkpoints?
Yeah, with "just mined" I thought you mean "mined the same day" or something like this - usually a block a (few) thousand blocks deep is selected.
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
// + Is surrounded by blocks with reasonable timestamps
// (no blocks before with a timestamp after, none after with
// timestamp before)
// + Contains no strange transactions
This part?
I'm trying to understand the whole file, I'll give it another good read tonight since I'm at work now ;-) but what do u mean by not just mined? I meant there can never be checkpoints for blocks not yet in the blockchain..
Not just mined, please read the comments in that file too. Generally yes though, a new client release usually also includes an updated checkpoint.
So the checkpoints are added afterwards? With every new version of the client a checkpoint of a block that was just mined is added?
Thanks
Thanks
Yes, you are correct. They are there so some quantum computing farm (doesn't exist, but...) can't come out of nowhere and roll back blocks by mining a long chain from far in the past.
Thats not really what they're for— though that have the effect too. Most of their usefulness is that they prevent a dos attacker from filling up bitcoin node's disk space with long runs of low difficulty blocks forked off low in the chain.e.g. you start off with difficulty 1 blocks at block 0, now mine-able by the millions by a single asic— _MAYBE_ a chain that starts off that way could eventually turn out to be the longest so absent the checkpoints a node would happily follow an endlessly long chain of them.
They also make is so that an attacker who has complete control of your network (and thus can prevent you from hearing the longest chain from the honest bitcoin network) from putting you on a fake (low difficulty) isolated chain unless they can also trick you into running replaced software. With the checkpoints such an attacker hast to have a ton of mining power in order to continue the chain.
A powerful quantum computer couldn't automatically change the rules of the network such as 1k-coin blocks. (If it could out-mine the entire network I guess it might also be capable of cracking everyone's ssh keys and passwords and hacking their system to replace bitcoin, but leaving that out, it can't change the rules.)
So they are added gradually as we reach there, this can only protect tampering with the existing data, there's no way to prevent future data tampering. Am I right? If the quantum computer comes out, then it just need to take the current blockchain, then change code and make new executable, by doing something like each block generate 1k coins, for example, and attach the new ones in the chain. This will overwrite the existing chain, though no previous data (checked by checkpoints) will be changed.
Yes, you are correct. They are there so some quantum computing farm (doesn't exist, but...) can't come out of nowhere and roll back blocks by mining a long chain from far in the past.
The whole point is to thoroughly check all the hashes from block 0 to today, that is how it's secure. It only has to check all of them once though, and then trusts that nobody will tamper with the disk data to invalidate that check (safe assumption, I think.)
The whole point is to thoroughly check all the hashes from block 0 to today, that is how it's secure. It only has to check all of them once though, and then trusts that nobody will tamper with the disk data to invalidate that check (safe assumption, I think.)
I am reading bitcoin codes, and I don't quite get what are checkpoints in the bitcoin code:
Are they hashes of the blocks at 11111,33333, etc positions? If so how can we precompute them, as going from 1 to block 225430 would take big amount of time of computations...
Quote
( 11111, uint256("0x0000000069e244f73d78e8fd29ba2fd2ed618bd6fa2ee92559f542fdb26e7c1d"))
( 33333, uint256("0x000000002dd5588a74784eaa7ab0507a18ad16a236e7b1ce69f00d7ddfb5d0a6"))
( 74000, uint256("0x0000000000573993a3c9e41ce34471c079dcf5f52a0e824a81e7f953b8661a20"))
(105000, uint256("0x00000000000291ce28027faea320c8d2b054b2e0fe44a773f3eefb151d6bdc97"))
(134444, uint256("0x00000000000005b12ffd4cd315cd34ffd4a594f430ac814c91184a0d42d2b0fe"))
(168000, uint256("0x000000000000099e61ea72015e79632f216fe6cb33d7899acb35b75c8303b763"))
(193000, uint256("0x000000000000059f452a5f7340de6682a977387c17010ff6e6c3bd83ca8b1317"))
(210000, uint256("0x000000000000048b95347e83192f69cf0366076336c639f9b7228e9ba171342e"))
(216116, uint256("0x00000000000001b4f4b433e81ee46494af945cf96014816a4e2370f11b23df4e"))
(225430, uint256("0x00000000000001c108384350f74090433e7fcf79a606b8e797f065b130575932"))
( 33333, uint256("0x000000002dd5588a74784eaa7ab0507a18ad16a236e7b1ce69f00d7ddfb5d0a6"))
( 74000, uint256("0x0000000000573993a3c9e41ce34471c079dcf5f52a0e824a81e7f953b8661a20"))
(105000, uint256("0x00000000000291ce28027faea320c8d2b054b2e0fe44a773f3eefb151d6bdc97"))
(134444, uint256("0x00000000000005b12ffd4cd315cd34ffd4a594f430ac814c91184a0d42d2b0fe"))
(168000, uint256("0x000000000000099e61ea72015e79632f216fe6cb33d7899acb35b75c8303b763"))
(193000, uint256("0x000000000000059f452a5f7340de6682a977387c17010ff6e6c3bd83ca8b1317"))
(210000, uint256("0x000000000000048b95347e83192f69cf0366076336c639f9b7228e9ba171342e"))
(216116, uint256("0x00000000000001b4f4b433e81ee46494af945cf96014816a4e2370f11b23df4e"))
(225430, uint256("0x00000000000001c108384350f74090433e7fcf79a606b8e797f065b130575932"))
Are they hashes of the blocks at 11111,33333, etc positions? If so how can we precompute them, as going from 1 to block 225430 would take big amount of time of computations...
Jump to: