Topic: Easy solution to prevent 51% attacks from doing any harm? (Read 1053 times)

That means that median of the last 11 blocks in the block chain.  If the miner mines on block 100,000, then he only has to set his timestamp after the median of blocks 99,989 - 99,999.  He doesn't have to worry around the main chain at all.

@greyman - wow thx a lot. I thought I know everything about Bitcoin, but that is new to me. So these 6 confirmations that people use are there for a reason. 

Actually, this IS already implemented, as I described in the following article:

http://btc-base.blogspot.sk/2014/01/bitcoin-transactions-why-it-is.html

Theoretically, though, I am not sure if the attacker couldn't try to fake the timestamp (he would set the timestamp of the first "private" block around one hour to the future).

that's it?

By golly, you've independently discovered distributed consensus! This is somewhat similar to how Ripple operates. I agree that manual intervention is a much more prudent solution than the idiot-proof "longest chain wins." At some point, you have to give some credit to the user's intelligence.

I don't understand. Can you explain in detail.  If most honest nodes in the network (which run 24/7) do not overwrite any blocks which are older than 6 confirmations  I don't see how  they like to reverse older transactions?  In the case that the merchant has only a few connection nodes and all of them are evil, he can double check on blockchain.info...

*Update

Ok here is how I understand it.  You say the attacker has his blockchain  0 -> F1 -> F2 ->F3  -> F4 ...-> F10 already mined   and releases  F1  the same second an honest miner releases his block 1 (block 1 following block 0). The attacker than releases  his block F2 exactly when an another honest miner releases Block 2  (2 following 1) and so on.  Now 3 cases:

*  If most honest miners now ignore F1 -> F2 -> ... -> F6  we don't have a problem because of the new security measure (as most miners and full nodes will just ignore the F-chain even if its longer)
*  If most honest miners will work on the F-Chain we won't have a problem as well.
*  If both chains are around equally  popular  full nodes will be fully aware that there is a fork and can send security warnings.  Merchants who run a simple node and have only limited connections can double check on sites like blockchain.info (which should alert a big red security warning while there is a fork)

No, if they make a concurrent fork then they could distribute the block to many nodes in the network after they have confirmed that they node they want to attack has received the transaction they wish to reverse.

Good point. The attacker could do that, however  transactions that are older than 1 hour could never be reversed!  And isn't that the whole point of an 51% attack?

The only thing an attacker could do is now

* prevent any transactions from happening
* reverse or double spend transactions that are younger than 1 hour.

which is very expensive and not that dangerous imo.

If a Merchant receives a big transaction he  could just wait 6 confirmations (maybe double check transaction on blockchain.info and blockexplorer.com) and even if the attacker is in full control for the whole time this transaction could not be reversed!

If someone has 51% of network power, what prevents them from creating a fork of the mainchain as the mainchain is being produced? They could release a block every time the mainchain block produces one. This would cause two different clients to see two different forks and have no consensus.

Hi folks,   I often read that many people are afraid of so called 51% attacks. I really don't  understand the big deal about it.  

********1st problem: Double Spend Attack*********

Here my solution: Can't we agree that our full Bitcoin Nodes never automatically overwrite these parts of the Blockchain that are older than let's say 1 hour  (or 6 confirmations).  Normally orphaned blockchains never contain more than one additional block, so there should not occur any problems.  

In the rare occasion that there is a longer fork and you have the shorter blockchain the program should ask for manual selection of the blockchain that should be used.  
For unlikely cases like

* http://bitcoin.org/en/alert/2013-03-11-chain-fork
* an real 51% attack
* Australia gets disconnected from the rest of the world  and you live in Australia  or whatever :-)

I think it would be safer if users can manually handle these events.  

*******2nd problem: Mining Empty blocks ********
Gavin also found a good solution (changing the protocol to reject longer chains in some cases): https://bitcointalksearch.org/topic/m.874553


******3rd problem: Prevent all other miners from mining any valid blocks  ********
If the attacker doesn't do double spend attacks and includes all transaction but just ignores all blocks from other miners it could be a problem. Other miners would soon go bankrupt and the attacker would gain even more % of the network....

I would suggest the same solution like with problem 1.  Any Miner or any Full Node shall not overwrite a Block that is older than 5min in the case that such an attack is ongoing.

******
  So overall I suggest to include a manually adjustable parameter, that allows every user to set the timespan in which overwriting existing blocks remains possible.  
In case of emergency it could be set to 5min
Full Nodes could set it to 60min  and  
simple Nodes  or Nodes with bad connectivity could set it to infinity....