monocolor (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 03, 2013, 06:00:50 AM |
|
I am reading bitcoin codes, and I don't quite get what are checkpoints in the bitcoin code: ( 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"))
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...
|
|
|
|
scintill
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 03, 2013, 06:11:50 AM |
|
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.)
|
1SCiN5kqkAbxxwesKMsH9GvyWnWP5YK2W | donations
|
|
|
monocolor (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 03, 2013, 06:23:51 AM |
|
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.
|
|
|
|
scintill
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 03, 2013, 06:40:02 AM |
|
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.)
|
1SCiN5kqkAbxxwesKMsH9GvyWnWP5YK2W | donations
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4242
Merit: 8672
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 03, 2013, 06:41:45 AM |
|
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.
|
|
|
|
tyrion70
Legendary
Offline
Activity: 934
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 07, 2013, 01:56:08 PM |
|
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
|
|
|
|
Sukrim
Legendary
Offline
Activity: 2618
Merit: 1007
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 07, 2013, 02:00:00 PM |
|
Not just mined, please read the comments in that file too. Generally yes though, a new client release usually also includes an updated checkpoint.
|
|
|
|
tyrion70
Legendary
Offline
Activity: 934
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 07, 2013, 02:14:26 PM |
|
// 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 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..
|
|
|
|
Sukrim
Legendary
Offline
Activity: 2618
Merit: 1007
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 07, 2013, 05:20:44 PM |
|
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.
|
|
|
|
bluemeanie1
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 17, 2013, 02:58:53 PM |
|
who makes the checkpoints?
|
|
|
|
jackjack
Legendary
Offline
Activity: 1176
Merit: 1257
May Bitcoin be touched by his Noodly Appendage
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 17, 2013, 03:01:39 PM |
|
who makes the checkpoints?
The bitcoin core devs
|
Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2 Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
|
|
|
bluemeanie1
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 17, 2013, 03:18:58 PM |
|
who makes the checkpoints?
The bitcoin core devs so ultimately, the state of the block chain depends entirely on them.
|
|
|
|
piotr_n
Legendary
Offline
Activity: 2053
Merit: 1356
aka tonikt
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 17, 2013, 03:25:24 PM |
|
who makes the checkpoints?
The bitcoin core devs so ultimately, the state of the block chain depends entirely on them. not really. they only put checkpoint for blocks that are buried at least few hundreds deep already - unlikely to be reverted by honest means. but if you disagree with any checkpoint they add, just don't upgrade your node and you will be fine.
|
Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E
|
|
|
bluemeanie1
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 17, 2013, 03:31:39 PM |
|
who makes the checkpoints?
The bitcoin core devs so ultimately, the state of the block chain depends entirely on them. not really. they only put checkpoint for blocks that are buried at least few hundreds deep already - unlikely to be reverted by honest means. but if you disagree with any checkpoint they add, just don't upgrade your node and you will be fine. well that's a practical solution, but it violates the notion of 'peer-to-peer' or equality for all nodes in the network. there is no indication of 'checkpoints' in the satoshi whitepaper. furthermore, if we rely on such checkpoints for security, why do we even have proof of work at all? Why don't we just rely on the checkpoints?
|
|
|
|
piotr_n
Legendary
Offline
Activity: 2053
Merit: 1356
aka tonikt
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 17, 2013, 03:34:12 PM Last edit: June 17, 2013, 04:11:50 PM by piotr_n |
|
yeah, I agree with you that it goes against an important principle, but as gmaxwell said, it does have some actual purpose, protecting your storage from being flooded by forks that would suddenly start to appear at low block numbers. though, it does not make any sense to have multiple checkpoints (instead of i.e. a one that moves by itself), but well... who are we to argue with a solution chosen by the best bitcoin developers that satoshi left behind? ![Wink](https://bitcointalk.org/Smileys/default/wink.gif)
|
Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E
|
|
|
kjj
Legendary
Offline
Activity: 1302
Merit: 1026
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 17, 2013, 05:17:41 PM |
|
who makes the checkpoints?
The bitcoin core devs so ultimately, the state of the block chain depends entirely on them. not really. they only put checkpoint for blocks that are buried at least few hundreds deep already - unlikely to be reverted by honest means. but if you disagree with any checkpoint they add, just don't upgrade your node and you will be fine. well that's a practical solution, but it violates the notion of 'peer-to-peer' or equality for all nodes in the network. there is no indication of 'checkpoints' in the satoshi whitepaper. furthermore, if we rely on such checkpoints for security, why do we even have proof of work at all? Why don't we just rely on the checkpoints? I'm having a hard time figuring out what you mean by "equality of all nodes". The equality (or inequality) of nodes is not part of the system. No one cares about nodes. We care about the chain. If a node has the correct chain and can give you a copy, it is "equal" to all of the other good nodes. If it doesn't, or can't, then it equal at all, isn't even a node. The checkpoints do not provide any security, nor were they ever intended to. They just keep "unequal" nodes from wasting your time with bogus chains (whether by accident or malice). Also, you are free to edit and recompile as needed. You can strip them out entirely, or add your own, or change them. Whatever you want. The reference client is written for (and compiled for) working well for a wide audience. Technically, a longer chain is the best chain, regardless of the checkpoints. In practice, the checkpoints are far enough in the past that if a new chain showed up that overturned one, we'd almost universally consider it an attack, and roll back. P.S. No one particularly likes the checkpoints, the devs least of all. There has been much discussion about removing them, or switching to a soft system (config file, etc). So far, no one has come up with a really good solution.
|
17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8 I routinely ignore posters with paid advertising in their sigs. You should too.
|
|
|
|
piotr_n
Legendary
Offline
Activity: 2053
Merit: 1356
aka tonikt
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 17, 2013, 05:22:04 PM Last edit: June 17, 2013, 05:36:02 PM by piotr_n |
|
P.S. No one particularly likes the checkpoints, the devs least of all. There has been much discussion about removing them, or switching to a soft system (config file, etc). So far, no one has come up with a really good solution.
I can come out with a really good solution, if you want ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) Just make a rule that the client would not accept any forks deeper than N blocks back from its currently known top. Set N to whatever constant you want, but I think more than a week time would be exaggerating.
|
Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E
|
|
|
bluemeanie1
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 17, 2013, 05:26:22 PM |
|
P.S. No one particularly likes the checkpoints, the devs least of all. There has been much discussion about removing them, or switching to a soft system (config file, etc). So far, no one has come up with a really good solution.
I can come out with a really god solution, if you want ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) Just set a dynamic limit in that the client would not accept any forks deeper than N blocks back from its currently known top. Set N to whatever you want, but I think more than a week time would be exaggerating. the fact is, if we've introduced a form of consensus OUTSIDE of proof-of-work, that overrides Proof-Of-Work, and that's precisely what checkpoints are- why do we have proof of work at all? can we remove proof of work, and have a block chain that is based on consensus between N parties? Yes! https://docs.google.com/file/d/0BwUFHE6KYsM0ZkxLVmFwbXQ3ck0/edit?usp=sharing-bm
|
|
|
|
piotr_n
Legendary
Offline
Activity: 2053
Merit: 1356
aka tonikt
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 17, 2013, 05:30:11 PM |
|
I think you don't understand. Checkpoints are not there to fight proof of work - they are there to protect your node from attacks.
Do you understand that if there were no checkpoints, anyone with a graphic card could just keep mining blocks that link to the genesis one, and this way fill up your hard disk? Also stuffing the net with useless data.
|
Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E
|
|
|
|