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

Is it clearly total work, rather than block height?

It is not just change of button color or font size, it is protocol specification change.
If one fork has checkpoints and other does not - then they do not have consensus on how to select main blockchain, and this could lead to blockchain fork (at least theoretically).
Bitcoin already has consensus mechanism, and it is the foundation - block-chain with bigger combined work amount is the winner, period.

In a same way as we have checkpoints now, it is possible to freeze BTC on particular address - tune a bit validation rountine (just like checkpoints validation), wait for update of majority of clients - and vu à la. I bet, governments would love this feature, keep going!
Any kind of such validation is poison to trust for the most important of Bitcoin features - decentralization.

I like this idea - it doesn't contradict decentralized principle (as checkpoints do).

Saved

There are two possibilities where this would not happen:

1. Either change enough bits in such a way that the hash stays the same. This is called a "hash collision".

2. Or perhaps insert a block which has the same hash, again a hash collission except it's doubled:  block 1.5 to be inserted has same hash as block 1, block 2 will happily accept block 1.5.

The blockchain is already a chain of hashes.  The hash for block 2 uses the hash of block 1 as (part of) its input and the hash for block 3 uses the hash for block 2 and so on.

If you were to change a single bit for block 10, then the hashes for all blocks from 10 onwards would change.  Ofc, that would mean that blocks 11 onwards would no longer meet the proof of work (which is the whole point).  You can't change anything without destroying the chain entirely.

The SHA-256 function breaks large messages into pieces for processing anyway.  It uses the output from one piece as the input into the next piece.

More like moving each cell to their own universe so if they escape they have nowhere to go.  I think you vastly misunderstand the odds we are talking about.

It's more like placing each criminal in it's own cell. Currently if one wall is blown up many thousands of criminals can escape.

By placing more walls around the criminals less criminals can escape if one wall were to be broken.

No preimage attack against SHA-2 is possible. 

Saying "it's already difficulty enough" is like saying it is already difficulty to walk through a wall due to quantum tunneling but just to be safe we should double up all walls in case someone gets "lucky".

No the opposite ofcourse, if he can find one, he can find two, or three or four, hence my suggestion to add as many hashes as possible.

So my suggestion is:

Check point hash 0 = Hash(block 0, block 1, block 2, block 3, etc up to block 2015)
Check point hash 1 = Hash(block 2016, block 2017, block 2018, etc up to block 2016+2016-1)
Check point hash 2 = Hash(block 2016 * Hash Number to (Block 2016 * (Hash Number+1))-1)
Check point hash 3 = etc

^ This will lead to many more hashes and best part is that all block hashes are included, not just a few, actually the entire block should be hashed, why stop at only block hashes ? Yes it would lead to more computational effort but that's basically the point in general, however perhaps block hashes only would be enough, it's already difficulty enough to fake one, however including all could give a bit more security because it adds dates, times, transactions, etc, but maybe could also lead to less security because of easy adjusting comments or other bogus information, with a hash only that would be a bit more difficult to do it could throw off all input calcultions to try and fake such a hash.Blocks can probably fluctuate in size, while for now the hash is always same size, so gives some constant speed and also easy to implement reliably without all kinds of potential strange block size quircks).

So, you are assuming that an attacker can find one has collision, but not two?  That doesn't make any sense.

The way the chain headers are hashed and linked makes bitcoin insanely strong against preimage attacks.  MD5 is considered to be totally broken, and preimage attacks on MD5 are rampant.  However, if we used MD5 (not even double MD5) as our blockheader hashing mechanism, we would still be totally safe.

P.S.  I didn't read much past the part that I quoted.  I hope you don't take any offense at that.  If you had other important things to say, please try to organize your thoughts better.

Satoshi answers your question in the original document:

"
The proof-of-work also solves the problem of determining representation in majority decision
making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone
able to allocate many IPs.
"

Currently bitcoin seems to be a system that uses both concepts: "confidence" and "proof of work".

The checkpoints can be considered a dirty hack to make bitcoin more secure, it's an admission that bitcoin in it's original concept/design was flawed and pretty much still is if it werent for this

However perhaps that last part of my sentence is a bit hasty... I do wonder if it's possible to insert a block anywhere in the chain if a hash collission was found.

I am not sure what kind of protective measures bitcoin has to protect against block insertion.

If these checkpoints are truely based on single blocks then it won't protect against insertions.

Thus a smarter hash would be a hash computed over the entire blockchain.

Such a hash could be included to protect against insertions. However if the attacker can calculate a hash collission then this would only double his calculation efforts.

However the point is: the more checkpoints, the better.

I think the solution to make it a little bit more secure is simply calculate a hash over the entire blockchain every 2016 blocks and store it.

At least this will increase computational resources needed to produce any fake chains and also makes insertion problematic.

However I am not so sure how easy it would be to create a "fake chain" that would be accepted by a bitcoin client if it did not have these checkpoints.

Perhaps the bitcoin client also calculates "difficulty" each 2016 blocks and would then detect that the difficulty on the fake block chain was not properly increased... (<- note flaw in logic, it can also decrease, fluctuate wildly, no rules govern it, explained and examined further below).

If the bitcoin client does not yet currently do this then it could start doing that to prevent fake chains in the future... this will make it harder for attackers to properly construct fake chains, since they will also have to increase the difficult and thus consume more hashing power.

However difficulty can be manipulated by simply pretending bitcoin was not popular at the time and there were little transactions and it took days and months to find a block, so ultimately it would probably get accepted unless some measurements based on history would be used but this could hamper future wild changes.

Biggest change in difficult was probably around 10 july 2010 when bitcoin was announced on slashdot... resulting in the slashdot effect, a jump in difficulty of 300%.

However using difficulty as a way to detect fake chains could have merit.

The idea for a fake block chain would be to "out race" the real chain.

This implies either:

1. The fake block chain has more blocks, and thus the blocks were found faster <- indicating something fishy might be going on with the difficulty, this could indicate the difficult was not properly increased each 2016 blocks.

2. The real block chain fell out of use, bitcoin became impopulair... difficulty was too high... not enough hashing power.... fake chain starts to over take it.

Option 2 could imply that bitcoin could be at risk as soon as it becomes impopular... it's difficult will start to drop... but at a slower pace then a fake chain.

A possible attack to create a fake blockchain could be:

1. Determine current ammount of blocks in the real chain.

2. Divide current ammount of blocks by 2016.

3. This indicates how many difficulty changes must be calculated.

4. Perhaps use a rollcoaster tactic:

5. Calculate as many blocks as possible with minimum difficulty.

6. This will cause the difficulty to shoot up to insanity.

7. Then stop calculating blocks for the next 2016 blocks.

^ Problem, cannot stop calculating, thus algorithm must be changed:

Spread difficulty over as many groups of 2016 as possible.

Possible attack vector:

Difficulty at start of chain was low, replace low difficulty with high difficulty to try and produce a constant difficulty.

Having a constant difficulty might be exactly what the attack would need, no more, no less, if this is better than the roller coaster approach is uncertain.

Perhaps the roller coaster approach has merit too I think so:

Roller coaster approach version 2:

Calculate as many blocks as possible without raising the difficulty to an unrecoverable state, keep it sane so that the next 2016 blocks can still be calculated.

Or other attack vector:

Spread the 2016 blocks over an enormous ammount of time... weeks, moths, years or so...

This will drop the difficulty back to minimum.

Then produce an enormous ammount of blocks.

So I think the roller coaster approach might be possible as long as it's not over done too much

So two possible attack vectors:

1. Roller coaster approach within reasonable difficulty recoverment/crash.
2. Constant difficulty approach.

However I assumes the roller coaster approach would be capable of generating limitless ammount of blocks within 2016. This is not the case. After 2016 blocks were produced it would recalculate the difficulty.

So now ask yourself one question: what would happen to the difficulty is 2016 blocks were generated in 1 second ?

What would happen to difficulty if 2016 blocks were generated in one month ?

Perhaps there is a possibility to roller coaster it in such a way that it would end up producing blocks faster than the real block chain... with less computation power needed... not sure...

I guess the answer lies in the "computation power" that is required at different difficulties relating to the hash itself.

If the computation power scales linearly with the difficulty.... then this attack may not work.

However if it's somehow possible to gain an adventage at lower difficulty then perhaps a netto sum effect is achieved, perhaps it will profit from the lower difficulty/lower computation power needed once it crashes.

Also perhaps other security checks are in place, such as checking the date/time for each block. Thus generating 2016 blocks in 1 second might not be possible/accepted by the clients ? Not sure about that...

Theoretically it might be desireable to still allow it, nothing prevents anybody from suddenly adding insane ammounts of computer power to the bitcoin network... if the bitcoin network could not scale up beyond a certain point that would be a bit strange I guess it's all about certain assumptions/sanity checks... difficult to predict the popularity of bitcoin... thus such sanity checks might hamper suddenly super popularity.

Such an event already happened with the slashdot effect: a 300% increased, as if 2 or 3 earths were added ? which could be precisely why these checks were not implace... it would have hampered it...

Time for some fun numbers:

There are currently: 271789 blocks.

Number of difficulty changes:

271789 / 2016 = 134.81597222222222222222222222222

Close to 135 difficulty changes.

That's a surprisingly low number of changes.

Let's assume a 2016 block can be generated in 1 second with minimum difficulty.

After it's generated some unknown ammount of time is needed to drop it back lower.

So 50% we can try and do in 1 second which gives:

134/2 = 67 difficulty changes.

These can be spread out over the entire time that bitcoin was running. Block 0 started at 2009-01-03 18:15:05

It's now 27/11/2013 17:38

That's a whole lot of years to spread 67 over...

Now I need to plugin the difficulty algorithm or code in bitcoin, I am not sure what it is but for now I will take this:

difficulty=((Time for a block to be found in seconds)*(hashes per second))/2^32

difficulty = 1/10.000 * ? / 2^32

not sure what hashes per second is supposed to be, perhaps the total estimated hashes per second. Perhaps 4 gigahash should be taken.

However all of this might not matter.

There seems to be a hard limit of 1/4x or 4x of what it previously took.

If true then we golden.

We might be able to produce a fake blockchain pretty easily.

1 second, 4 seconds, 16 seconds, 64 seconds, and so forth.

Ofcourse this is exponential...

But to reset the algorithm, we simply mine the next 2016 in 4 or 8 seconds to crash it back to 1.

Thus creating a fake blockchain would seem very easy as long as these minimum and maximum multiplication factors are in place.

Hence the need for these checkpoints... it's the only thing prevent a fake block chain from taking over ?

It doesn't happen that often.

However, I meant total PoW for the chain.  This is the sum of the PoW for all blocks from the genesis block to the last block in the chain.  That always increases and even if a new main chain takes over, by definition, it has more PoW.

The spam DoS attack was to create 2015 difficulty 1 blocks that are 1MB each.    You can create as many of those as you want and they are valid forks of the chain, so are stored.

If only forks with lots of total PoW are stored, then that is less of a problem, since those blocks require high PoW.

With a 51% attack, you could drop the difficulty back to 1, so there is still some risk.  However, by dropping checkpoints, you are inherently assuming that is no possible.


That is what I meant by MAIN_CHAIN_MIN_POW, it would be the minimum total work before a chain can be called the main chain. 

I think it would be cool for checkpoints to be distributed periodically in dead tree format.

Fair enough— for whatever it's worth, I'm no fan of them either. If nothing else they really create a hard time for people reasoning about the security model of Bitcoin: There are a lot of people who have a hard time getting how the POW consensus works and then they hear about the checkpoints and say "Ah ha! this is how its secure!", after all people are familiar with centralized security so this is just a lot easier to understand.

The big damage from that comes because we're then subjected to a non-stop stream of IDEAS and IMPROVEMENTS from people who's understanding of the security model was broken by the mere existence of checkpoints, even though checkpoints do nothing relative to consensus. These people propose things which depend on a centralized security model and don't have the benefit of the checkpoints being set thousands of block in the past so they are never a practical influence on the consensus, and don't spend the mental cycles trying to fit their ideas into the real, primarily zero trust, Bitcoin security model. As a cautionary sign of where that could be going: There altcoins which user developer controlled checkpoints broadcast to checkpoint blocks in real time, and more altcoins being added that do this... as if this were an acceptable way to construct a decentralized cryptocurrency!

When headers first syncing is merged, just by adding a "must be this tall" minimum sum difficulty check we'll be able to remove checkpoints for all DOS purposes, and we'll also be able to remove them for syncing acceleration (using random sampling for ECDSA in the deeply burried chain).

Checkpoints as a cognitive security blanket against doomsday reorgs will likely stay, but we could update them less frequently, with a more regimented process, and perhaps change how nodes respond to them (e.g. a conflicting chain becoming longer making all nodes go into a safemode where they regard everything new as unconfirmed, process no transactions, and discourage any new blocks that process transactions allowing for a public resolution of the "impossible event", rather than directly coercing the consensus).

Well he seemed to think the fact that they are included at all = the death of Bitcoin.  I was just providing a way for him to "save" Bitcoin from the ebil developers. 

Yup, I just mentally corrected TierNolan's proposal to match ones made by many people before— have a minimum total chain work checkpoint (e.g. any valid chain will have at least 2^70 work by height XXX). That allows the same protection from spamming as the current stuff.

Uhhhhhh. Or just run with the checkpoints=0 command-line/config option.

You are free to use and distribute a fork of the client without any checkpoints.  Checkpoints aren't required. Assumming an attacker isn't attempting to DDOS your node by filling it with years worth of bogus blocks or try to perform a 51% attack months deep in the chain the lack of checkpoint will have absolutely no effect on your node.

So if you are worried then remove the checkpoints, compile it and use that node.  If you are really worried set up an online mirror and advertise your checkpoint free version.

See peer to peer at work.

Haven't there been periods where the difficulty went down?

Then you pick among them like normal, the point there is to close of the denial of service attack without undermining the consensus algorithm with an element of centralization.