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