Pages:
Author

Topic: What are checkpoints in bitcoin code? - page 2. (Read 14791 times)

newbie
Activity: 28
Merit: 0
December 20, 2013, 10:43:32 PM
#73
There would be no way to prove that they are part of the chain.

Yes - I considered this. I think it is not a problem, because it is very unlikely that someone can prepare 0.01*MaxBlocks different blocks (unchained, as you noted) which have accumulated difficulty more than 1% or so of total accumulated work spent on main chain for whole time of Bitcoin existence.

In the High hash highway, a second pointer is added.  Headers would have a link to the previous block and also an "up" link.

This allows you follow backwards from the leaf of the chain much faster, but still hit all the high blocks.  However, it is a hard fork.

The 2nd link points to the nearest block with more leading zero bits than the previous block.
I should look closer to your proposal. For now I have one question:
Does "up" link points to future? If so - is it included in block hash or can it be falsified?
legendary
Activity: 3416
Merit: 1912
The Concierge of Crypto
December 20, 2013, 09:50:11 PM
#72
I think the checkpoints are about at least a month or two back in time. Anyone who has more than 51% of 6.5 Petahash of mining power that can fork their own chain past the latest check point, is better off mining regularly and getting 51% of 3600 coins daily or about 1800 coins, at least for the next 2000 blocks when the difficulty will double.
legendary
Activity: 1232
Merit: 1084
December 20, 2013, 09:29:16 PM
#71
we should add ability to request block headers sorted by difficulty, starting with the most expensive one and continue in descending order. This would allow to detect flood with even less traffic, like few percents of Max_Blocks.

There would be no way to prove that they are part of the chain.

In the High hash highway, a second pointer is added.  Headers would have a link to the previous block and also an "up" link.

This allows you follow backwards from the leaf of the chain much faster, but still hit all the high blocks.  However, it is a hard fork.

The 2nd link points to the nearest block with more leading zero bits than the previous block.

In fact, I think optimal would be, point to the block after the nearest block with more leading zero bits than the previous block.

So, the blocks had the following leading zero bits

A) 30
B) 31 - up -> genesis (since 30 is the best so far)
C) 29 - up -> genesis (since 31 is the best so far)
D) 33 - up -> C
E) 31 - up -> genesis (since 33 is the best block)
F) 32 - up -> E
G) 30 - up -> E
H) 32 - up -> G

If you follow the up link backwards, you go to a block that is the successor of a block with at least 1 more leading zero than the previous block.

To find the highest block, these are the steps

- Set N to the index of the leaf block
- Set b to the number of leading zeros for block N-1

Loop
- The up pointer for block N points to block M
- Block M-1 has more leading zeros than block N-1 (by definition)
- It also has more leading zeros than any blocks from N-1 to M, inclusive
- This means you can't have skipped a better block than block M-1
- set N = M
- set b = the number of leading zeros for block M-1

Each time through the loop b is guaranteed to increase and also you are guaranteed not to skip the best block.

Therefore, this search will find the best block.

The PoW of the main chain can be estimated just by looking at the work of the best block.

You can also use the system to find all blocks which have difficulty within a number of bits of the best block.
newbie
Activity: 28
Merit: 0
December 20, 2013, 07:50:31 PM
#70
I think the headers first change is a key stepping stone for this.

Downloading 300k blocks is around a 20MB download.

With modern bandwidth, nodes could download that from 8 peers reasonably quickly and then discard any chain that doesn't have sufficient POW.

I agree, for now and most likely for future downloading all block headers is not an issue. So don't even need to adjust protocol.
newbie
Activity: 28
Merit: 0
December 20, 2013, 05:28:47 PM
#69
It would be cool if someone could work out a formula.
Max blocks = f(time since genesis, POW)

Yes, this is the key for improvement. It does not have to provide strict upper_bound, but something that >= strict_upper_bound.
Plus, if this approach will be accepted, we should add ability to request block headers sorted by difficulty, starting with the most expensive one and continue in descending order. This would allow to detect flood with even less traffic, like few percents of Max_Blocks.
legendary
Activity: 1232
Merit: 1084
December 20, 2013, 10:46:15 AM
#68
Not everything goes to BIP.  This is a purely internal function of the reference client.  Most discussion of changes like this actually happen on github, attached to the pull request that implements them.

I think the headers first change is a key stepping stone for this.

Downloading 300k blocks is around a 20MB download.

With modern bandwidth, nodes could download that from 8 peers reasonably quickly and then discard any chain that doesn't have sufficient POW.

The more blocks in a blockchain, the higher the total POW.  It would be cool if someone could work out a formula.

Max blocks = f(time since genesis, POW)
kjj
legendary
Activity: 1302
Merit: 1025
December 20, 2013, 08:51:05 AM
#67
Cool.  When can we expect your patch?

I think this idea should be discussed first in separate topic. Then, as I understand it should go to Bitcoin Improvement Proposals.

Not everything goes to BIP.  This is a purely internal function of the reference client.  Most discussion of changes like this actually happen on github, attached to the pull request that implements them.
newbie
Activity: 28
Merit: 0
December 20, 2013, 05:08:55 AM
#66
Cool.  When can we expect your patch?

I think this idea should be discussed first in separate topic. Then, as I understand it should go to Bitcoin Improvement Proposals.
sr. member
Activity: 280
Merit: 257
bluemeanie
December 16, 2013, 07:10:50 PM
#65
I am reading bitcoin codes, and I don't quite get what are checkpoints in the bitcoin code:

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

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


they're what make Bitcoin not Peer-To-Peer.

kjj
legendary
Activity: 1302
Merit: 1025
December 16, 2013, 07:01:05 PM
#64
Way back on post #5 gmaxwell explains it pretty well.

Again, it is possible to solve this problem by other approaches.
For example via MAIN_CHAIN_MIN_POW as suggested above - it does not compromises decentralization.

We know when Bitcoin was released, we know current date - we can calculate upper bound for block count in any chain.
When somebody tries to send us old chain - we ask it to sent block headers sorted by difficulty, starting with the most expensive one and continue in descending order. 1% of top block headers should have at least 0.01*MAIN_CHAIN_MIN_POW accumulated difficulty, if it is not - then it is fake, else continue, and so on.

Cool.  When can we expect your patch?
newbie
Activity: 28
Merit: 0
December 16, 2013, 05:24:05 PM
#63
Way back on post #5 gmaxwell explains it pretty well.

Again, it is possible to solve this problem by other approaches.
For example via MAIN_CHAIN_MIN_POW as suggested above - it does not compromises decentralization.

We know when Bitcoin was released, we know current date - we can calculate upper bound for block count in any chain.
When somebody tries to send us old chain - we ask it to sent block headers sorted by difficulty, starting with the most expensive one and continue in descending order. 1% of top block headers should have at least 0.01*MAIN_CHAIN_MIN_POW accumulated difficulty, if it is not - then it is fake, else continue, and so on.
kjj
legendary
Activity: 1302
Merit: 1025
December 16, 2013, 04:47:22 PM
#62
You didn't actually read this thread before posting, did you?

I did read this thread, and several old ones: https://bitcointalksearch.org/topic/bitcoin-032-released-437 , https://bitcointalksearch.org/topic/bitcoin-is-not-as-advertised-1647
Do you have any particular objection to discuss?

Way back on post #5 gmaxwell explains it pretty well.

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.
newbie
Activity: 28
Merit: 0
December 16, 2013, 04:31:13 PM
#61
It's an optimization that can be disabled with a command line switch.

Even if it was done for the purposes of optimization - it is still protocol specification change. Clients with disabled "optimization" could accept some branches which would be rejected by client on default settings.

There are other possible approaches to do such kind of optimization, for example MAIN_CHAIN_MIN_POW described above, but it does not compromises decentralization trust as checkpoints do.
legendary
Activity: 1400
Merit: 1009
December 16, 2013, 04:21:06 PM
#60
Protocol rules allows to choose other branch if it has more accumulated difficulty, even if it is rooted in old blocks before checkpoints. Checkpoints override those rules - they essentially change protocol specification. By adding new checkpoint - you are forking protocol specification.
Choice of checkpoints should be done decentralized - by voting, and Bitcoin already has voting mechanism - vote by computing work. But if voting happens by hard checkpoints, selected by dozen of people - then it is centralized, with all bad sides of centralization.
It's an optimization that can be disabled with a command line switch.
newbie
Activity: 28
Merit: 0
December 16, 2013, 04:18:01 PM
#59
I don't understand how you think that checkpoints mean that a small group of people is deciding which branch is correct.

Checkpoints were put by small group of people, most of people even do not heard about checkpoints - and continue to think about Bitcoin as pure decentralized currency, while it is not.

The protocol rules chose the correct branch.  The checkpoints only document what that historical choice was.

Protocol rules allows to choose other branch if it has more accumulated difficulty, even if it is rooted in old blocks before checkpoints. Checkpoints override those rules - they essentially change protocol specification. By adding new checkpoint - you are forking protocol specification.
Choice of checkpoints should be done decentralized - by voting, and Bitcoin already has voting mechanism - vote by computing work. But if voting happens by hard checkpoints, selected by dozen of people - then it is centralized, with all bad sides of centralization.
legendary
Activity: 1246
Merit: 1001
December 16, 2013, 03:57:13 PM
#58
Bitcoin is decentralized. And no small group of people should decide which branch is correct and which is not.

I don't understand how you think that checkpoints mean that a small group of people is deciding which branch is correct.

The protocol rules chose the correct branch.  The checkpoints only document what that historical choice was.

newbie
Activity: 28
Merit: 0
December 16, 2013, 03:16:58 PM
#57
You didn't actually read this thread before posting, did you?

I did read this thread, and several old ones: https://bitcointalksearch.org/topic/bitcoin-032-released-437 , https://bitcointalksearch.org/topic/bitcoin-is-not-as-advertised-1647
Do you have any particular objection to discuss?
kjj
legendary
Activity: 1302
Merit: 1025
December 16, 2013, 03:12:41 PM
#56
Bitcoin is decentralized. And no small group of people should decide which branch is correct and which is not.
Checkpoints hardcoded in code were selected by small group of people.
But if Bitcoin is still claimed to be decentralized, not controlled by government, small group of people (who can be blackmailed, or forced by thermo-rectal cryptanalysis) - then only majority of users should have right to make decision.

Users should vote on which branch is correct and which is not. Bitcoin already has such voting mechanism - vote by computing power.


Of course hidden fork crunched at high speed in shadow is unlikely, and maybe checkpoints do not harm due to low probability of such fork.
But they harm in other way - they compromise Bitcoin decentralization, which is in my opinion is the biggest attractive feature of Bitcoin.
Today they add checkpoints, tomorrow they could freeze BTC on your address, by adding small tweaks to validation routine (just like checkpoints validation).

Checkpoints add almost no value - they do not prevent offensive usage of high computing power, but they trading off fair amount of credibility.
Nobody except majority should have control over blockchain, and Bitcoin's definition of majority is computing power.
Otherwise users must know that blockchain is controlled by small group of human being.

You didn't actually read this thread before posting, did you?
newbie
Activity: 28
Merit: 0
December 16, 2013, 02:58:02 PM
#55
Bitcoin is decentralized. And no small group of people should decide which branch is correct and which is not.
Checkpoints hardcoded in code were selected by small group of people.
But if Bitcoin is still claimed to be decentralized, not controlled by government, small group of people (who can be blackmailed, or forced by thermo-rectal cryptanalysis) - then only majority of users should have right to make decision.

Users should vote on which branch is correct and which is not. Bitcoin already has such voting mechanism - vote by computing power.


Of course hidden fork crunched at high speed in shadow is unlikely, and maybe checkpoints do not harm due to low probability of such fork.
But they harm in other way - they compromise Bitcoin decentralization, which is in my opinion is the biggest attractive feature of Bitcoin.
Today they add checkpoints, tomorrow they could freeze BTC on your address, by adding small tweaks to validation routine (just like checkpoints validation).

Checkpoints add almost no value - they do not prevent offensive usage of high computing power, but they trading off fair amount of credibility.
Nobody except majority should have control over blockchain, and Bitcoin's definition of majority is computing power.
Otherwise users must know that blockchain is controlled by small group of human being.
newbie
Activity: 28
Merit: 0
December 15, 2013, 11:44:17 PM
#54
Is it clearly total work, rather than block height?

Yes, it is total accumulated work.
Pages:
Jump to: