The way how to double protection bitcoin network against 51% attack

[ovidiusoft]

Yeah and absolutely no deniability.  So when the news starts running reports on this massive global cyber attack and all the evidence points to Bank Of America and you have employees and contractors whistle blowing that is going to look great.  Even if they don't suffer any civil or criminal charges the negative PR would be in the tens if not hundreds of millions of dollars.

Why would they need to deny anything? They will ride it as the best thing they did since inventing credit cards - they saved the world consumers from the claws of secretive money-laundering illegal drug-consuming tax-evading anarchists! They might even get tax deductions for their heroic efforts. They will also most likely have the approval of law enforcements agencies. "Sorry, ma'am, I know it's hot and noisy in our office, but we're fighting against cyber terrorists, so your money can be safe in our bank."

This has happened before (more than once): representatives from antivirus companies break into botnet C&C servers and shut them down. Good for them, the general public and the media say. But in reality, the are illegaly hacking into computers hosted in another country, computers who are sometimes owned by botnet masters or used with permission. Without a court order, most often than not even without informing local law enforcement. The are cyber attackers just like the botnet operators. They are heroes.

Question: if I break into a stolen car and I dismantle something so the car is unusable, am I a hero? Or did I just do something illegal? Both?

I'd say we shouldn't underestimate the power of FUD/PR. If Bitcoin will die, I think this is where the fatal blow will come from.

[1714816444]

1714816444

[1714816444]

1714816444

[1714816444]

1714816444

[1714816444]

1714816444

[1714816444]

1714816444

[Gavin Andresen]

The most important metric would be when the block was received.  If I receive a block that tries to replace a block 6 or 10 or 100 blocks ago on the chain I already know about, and I have no reason to believe I've been segregated from the network at large, I'm not going to vouch for it.

Yes.

The times the blocks are announced also matters; if my node suddenly sees a longer 10-block chain it has never seen before, then either it is a 51% attack or the network was split and just came back together.

If the network was split 10 blocks ago then I should see that those 10 blocks took twice as long to create as expected.

Rating blocks is a neat idea; I can think of several potential criteria, there are probably more we could come up with:

• Did I first see the block announcement long after the block's timestamp?
• Does it look like it is part of a network split?  (two chains that are both producing blocks more slowly than usual)
• Are they part of a sub-chain with a 'normal' distribution of blocks from the well-known mining pools? (an attacker's chain won't have blocks from ANY of the mining pools)
• Does it contain any double-spends that conflict with alternate chains I know about?
• Do the transactions in it look 'normal'?  (reasonable number of transactions, reasonable amounts)

Somebody should simulate some 51% attacks and network splits and try out various detection algorithms.

And maybe see if it would be practical to have a checkpoint lock-in rule of something like "auto-checkpoint any AAA-rated block once it is 4-deep in the best chain". I don't think that should be built-in to bitcoind, but a little side program that monitored the block chain and the pools and told bitcoind to add a checkpoint once an hour or so would be pretty spiffy...

[paraipan]

yay, i just realized we have lots of methods that we could combine and help detect or mitigate any 51% attack.

[DeathAndTaxes]

And maybe see if it would be practical to have a checkpoint lock-in rule of something like "auto-checkpoint any AAA-rated block once it is 4-deep in the best chain". I don't think that should be built-in to bitcoind, but a little side program that monitored the block chain and the pools and told bitcoind to add a checkpoint once an hour or so would be pretty spiffy...

This is the first suggestion (combined w/ heuristic block ratings) that makes me think one could make it very difficult to pull off a 51% attack.  I am already convinced there is no such thing as an economical 51% but heuristic block scoring and auto-lock checkpointing (if widely used enough) could keep the majority of the network on the "good chain". 

Your comment on differences between blockchain split and 51% attack are also insightful.  If the network splits and re-orgs the timing of the prior blocks should be longer than normal.

Some elements on heuristic block scoring:
* the block was first scene by multiple points in the network
* the signer of the block (if a known signer.  database of know reward addresses could be used)
* length of prior block(s)

[ByteCoin]

If the network was split 10 blocks ago then I should see that those 10 blocks took twice as long to create as expected.

This would be the case for a network split where one of the parts has roughly half the hashpower. An even split cannot be expected or relied upon. Block chain reorganizations as a result of network reconnections are likely to be complex events and I think that simple rules for coping with them yield the least unpleasant surprises.

A better metric for inferring an attack would be to estimate the implied aggregate hashpower. If a longer blockchain arrives that invalidates the last 10 blocks and the generation rate has been normal then one could reasonably infer that the aggregate hashpower has doubled and that there is cause for concern.
A reorganization which contains double spends would certainly be suspicious.

I would not recommend inferring anything from timestamps, the originating miner's identity or transaction amounts/numbers/sizes. Such rules would contain arbitrary hard-to-justify "magic numbers", be difficult to test, have complex failure modes and a large security perimiter.   

And maybe see if it would be practical to have a checkpoint lock-in rule of something like "auto-checkpoint any AAA-rated block once it is 4-deep in the best chain".

What should be done if a new chain arrives which invalidates an AAA rated block at depth 4 but now the new chain has incoming AAA ratings. The added complexity of sorting out conflicting ratings will have lots of nasty edge cases and be hard to test.

ByteCoin

[kjj]

I still prefer my idea of adding exponential difficulty deltas beyond a shallow reorg.  It doesn't require that the client track any new data sources and it doesn't require an AI to interpret trends.  It also allows a recipient to calculate a waiting time (depth really) for an incoming transaction that provides them with whatever level of concrete mathematical security they desire.

How it would work if you missed all of my posts on this last summer and fall:

First, we want to be able to handle ordinary "honest" reorgs exactly like we've been doing it.  The usual estimate I use for this is once every 300 blocks on average for a single block shuffle.  The reorglog on block explorer says there have been 29 reorgs in the 23523 blocks, or about 1 in 800.  In practice, blockexplorer will be on the winning side about half the time (and thus not record a reorg), so the real number is 1 in 400, which means that my 1 in 300 estimate is fairly close, and is on the conservative side.

That means that on average, we will get a single block reorg every other day.  And a two block reorg every other year.  And a three block reorg twice per millennium.  Beyond that, it gets silly, because there probably won't be an honest six block reorg before the sun burns out.

So, we pick a parameter, call it S, and set it to a number higher than we ever expect to see from an ordinary reorg.  6 would probably be good here, but just to be really safe, I'll go with 12 in my example.

Now, any reorg of depth <= S is handled normally.  The fun happens when an attacker wants to replace more than S blocks in a single shot.

I'm going to call the second parameter P, and it is the base of the exponential function.  Any number greater than 1 will work here.  Bigger numbers work more quickly, but small numbers still work great.  For this example, I'm going to go with 1.05.

Now, we do some calculating.  We go back in our chain to the last common ancestor, the point where the potential new chain split off.  We add up all of the difficulty stored in the blocks after this point, and we call it X, while we are doing that, we count how many of our blocks will need to be thrown out if the reorg succeeds, and we call that D.  Then we add up all of the difficulty beyond this point in the new chain, and we call it Y.  Finally, we calculate F=P^(D-S).

With me so far?  We have:

D - depth of the reorg from our point of view, the number of blocks that will be invalidated
X - difficulty of the reorg, again from our point of view, the amount of work that will be discarded
Y - difficulty of the new chain, the amount of work that will replace X
S - the number of blocks we are discarding
F - The exponential difficulty function that starts small, but grows more or less rapidly

Again, if D <= S, then the comparison is just is Y>X?  If yes, then reorg, if no, then no reorg.  This is simply the current logic.
However, if D > S, then the comparison is Y>(X*F).

If we assume blocks of constant difficulty, P=1.05 and S=12, we get:

12 blocks requires 12 * 1.00 blocks = 12.00 = 13 blocks (the new chain must be longer)
13 blocks requires 13 * 1.05 blocks = 13.65 = 14 blocks
14 blocks requires 14 * 1.10 blocks = 15.43 = 16 blocks
15 blocks requires 15 * 1.15 blocks = 17.36 = 18 blocks
21 blocks requires 21 * 1.55 blocks = 32.57 = 33 blocks (the chain is 50% stronger after just 3.5 hours)
24 blocks requires 24 * 1.79 blocks = 43.10 = 44 blocks
27 blocks requires 27 * 2.08 blocks = 56.13 = 57 blocks (twice as strong after 4.5 hours)
36 blocks requires 36 * 3.22 blocks = 116.10 = 117 blocks
60 blocks requires 60 * 10.4 blocks = 624.07 = 625 blocks (ten times the work needed after 10 hours)
144 blocks requires 144 * 626 blocks = 90229 blocks (after a day, the attacker needs to do over 600 times as much work)

The typical objections to my scheme involve honest network partitions.  I don't see that as a problem.  The worst case would be the network split exactly in half (by hashing power, not node count or geography), and staying divided for about 4 hours (assuming S=12), which is something we would notice, since it would involve aliens blowing up all of our communication satellites and putting the earth on a gigantic bandsaw to cut it into halves along a great circle through Minnesota and Texas.

[2112]

The single company running largest exchange, largest pool, largest rating service?  Kinda flies in the eye of decentralized.

Well, it depends on how you define "centralized." Currently Bitcoin is 100% owned by the mining cartel. I think that among the "core developer" only Gavin isn't running a mining operation. So if Mt.Gox or other exchange succeeds at breaking into the mining cartel then Bitcoin will actually become more diversified.

You do understand that waiting is no protecting from a 51% attack right?   The attack chain would be built in secret.  It wouldn't be released until it is longer than the valid change.  So a block rated quadruple AAAA would instantly be erased without warning by a longer chain and the transaction replaced.

In a Bitcoin client unrated blocks could never replace rated blocks. So the 51% attack as it is known now would be a threat only for those who don't trust any rating service: hard-core anarchists, people from the fringes of society, etc. For everybody else the rating services will be the defense. Some will buy the ratings online, some will periodically download the ratings in the public library, very much like the access to financial ratings is happening right now. There is whole spectrum of speed-of-access vs. cost trade-offs that are possible.

Obviously the current hard-coded values in the clients will need to change: 6, 150, 500, probably many others. Right now the trust spectrum is: 100% gavinandresen & fabianhjr, 0% all others. This should change in the future.