Author

Topic: 51% attack tamed, hogtied, tagged, and sent to the butcher (Read 1032 times)

full member
Activity: 182
Merit: 100
Love the end quote. I think my idea is a more in-the-stream real time version of what you suggest and it plays on consistent features, like image recognition.

Yours would work to an extent, it could be voted in, but now we don't know what transactions are real anymore. So magically appearing coins...
legendary
Activity: 1190
Merit: 1000
A solution to a 51% attack could be that forks longer than the current accepted chain to be merged into the chain, instead of replacing it. A different treatment for orphaned blocks so to speak. Of course, this results in more of a tree than a chain. That way at least, hashing can only add to the network.

How to accomplish this in practice and maintain the integrity of transactions is not something I have thought through. So, I leave the rest of the puzzle to the reader. Hanc marginis exiguitas non caperet, so to speak.
full member
Activity: 182
Merit: 100
BitcoinEXpress started this thread on solving the 51% issue: https://bitcointalksearch.org/topic/delete-96255
Ignore the fact that he's asserting some debatable points about his actions. That's been hashed to death.

I'll keep brainstorming in that thread but here's a completely decentralized solution to the 51% attack:

What is the nature of the 51% attack?
It is a single monolithic but decentralized network coming apart that is always ready to combust. That gives us the 50% + small edge parameter. A cursory study of chaos theory would tell you a truly decentralized system allows no monolithic attributes, ie. single difficulty, single hashrate target, etc. However, we don't need to modify those yet.

What we need to do is turn this monopolar model into a multipolar model. Any large attacker can make it bipolar. If we're going to have 2 poles then it's like two orbiting planets eventually crashing into each other. So either monopolar which is unstable or multipolar which is more flexible. Then 51% can become maybe 66.6%, 75%, 80%, 83.3%, 85.7%, 89.1%, 90%, etc.

Split the attack into two challenges or more perhaps like so:
Every block that's created must be submitted in portions but only the longest block with the consistently longest portions (at least 80%) in a row will be accepted.
This will lead to race conditions between multiple attackers. The blockchain is a managed self consistent race condition.
Instead of gaining control they may only be able to choke the network into a long context war.

The forking is solved because the possibility of gaining control is diminished with multiple attackers, but now we have the issue of drawn out battles.

So let's use our heads. What does a healthy chain look like?
No fever or cold sweats (way too high difficulty or way too low hashrate).
No sudden breakouts (blind merger as with the "attack").

Therefore the correct chain would be the one where the miners who were not knocked our during the tell tale DDoS are still producing at the same or similar rate.
In other words, assume the drop is a forced one and compare the hashrate against the participation rate. The fork with the least change in rates/participant and the longest most consistent (most partial blocks are longest) blocks is the correct one.

Think of the fair division of cake problem or a pile of loot with multiple thieves. What method allows the fairest distribution? Transplant the solution to that to the blockchain context.

More of this type of problem solving will be added here: http://antishock.tumblr.com

By the way, the blockchain is starting to sound like an operating system kernel and it would be wise to use ideas from that space to solve problems.

Hell, evolution and biological strategies for survival can also inform this issue.
Jump to: