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

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.

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?

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.

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.

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.

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.

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)

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 this idea should be discussed first in separate topic. Then, as I understand it should go to Bitcoin Improvement Proposals.

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

Cool.  When can we expect your patch?

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.

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

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.

It's an optimization that can be disabled with a command line switch.

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.


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.

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.

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?

You didn't actually read this thread before posting, did you?

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.

Yes, it is total accumulated work.