Topic: How exactly would a 51% attack work? (Read 19356 times)

Is this post of 2 years as relevant as now?

I didn't say miners attempt to do work that has already been done. I said they often do the same work in parallel. The page that you linked to confirms what I'm saying:
"Given just [the header] fields, people would frequently generate the exact same sequence of hashes as each other and the fastest CPU would almost always win."
It doesn't matter if the hashes are the same or not. The fastest CPU (or group of CPUs) almost always wins simply because it's faster. My point is further confirmed by BTC guild's finding four consecutive blocks with a few minutes.
http://hackingdistributed.com/2014/01/01/btc-guild-selfish-mining/

The article goes on to say:
"However, it is (nearly) impossible for two people to have the same Merkle root because the first transaction in your block is a generation "sent" to one of your unique Bitcoin addresses. Since your block is different from everyone else's blocks, you are (nearly) guaranteed to produce different hashes. Every hash you calculate has the same chance of winning as every other hash calculated by the network."
So you're right about the blocks being different. But they aren't completely different. In fact, the vast majority of transaction data is the same. And, again, it doesn't matter if the hash results are different, it's redundant because the same algorithm is ultimately being applied to multiple instances of the same transaction data.

Once again making false statements as fact.  Why not say "I believe it is redundant" or "I can't see a scenario where miners unknown to each other don't duplicate work accidentally?".  You state you don't know much about Bitcoin but you feel confident about making absolute statements of fact about something you don't know much about?

The different computers (1, 2, a trillion it doesn't matter) use different inputs and thus (barring some isolated implementation errors) never attempt work which has already been attempted.  Miners aren't hashing some random value, they are hashing the blockheader and Satoshi designed it so there would be no duplication of work.

https://en.bitcoin.it/wiki/Block_hashing_algorithm

Even if everything else is the same in a block, the coinbase tx for each miner will be unique and thus the hash for that tx will be unique and thus the merkle tree will be unique and thus the merkle root hash will be unique and thus the blockheader will be unique.

There's some great information here explaining the 51% attack.

One thing I didn't see mentioned was how Satoshi was planning on building a 51% attack defense into the code. But he got spooked and vanished after Gavin informed him that he was going to talk to the CIA/feds about Bitcoin. A few years after Satoshi's disappearance, a young Canadian programming student studied the existing code and engineered the missing 51% defense system that Satoshi was unable to complete.

This is the system currently integrated in Goldcoin (GLD).

You really think so? -_-

That is 100% incorrect.  In the future how about phrasing things you don't know as a question.  There are no redundant attempts on each block (baring the implementation issue at a specific pool where the pool incorrectly issues the same work to more than one worker).

I did this once. Went to that bar in Orlando that accepts Bitcoin. Bought a beer and some nachos and paid in Bitcoin. What they did not know is that I overclocked my CPU at home to 66MHz and executed the 51% attack perfectly.

By the time I walked out, the Bitcoin I had used to buy the beer was back in my wallet and nobody was the wiser.

Though when I got home, my overclocked computer was fried. Lost all of my favorite gifs and clean Win3.1 install.

Thank you for explaining this so well, I'm new to Bitcoin so I'm looking into all the flaws before I dive in.. So thank you.

That is correct.  IIRC Amazon has only ~10K of those GPU instances.  Also Amazon puts limits on the number of instances one person can purchase.  It isn't completely anonymous (they don't want the bad press of say Iran finally perfect nuclear detonation timing using EC2 instances).  After the Sony hack, in which the attackers used Amazon instances, there is a lot more cross checking of instances.  Large number of similar instances run by "different users" is very likely going to get audited/halted.

If you need 100 nodes EC2 is viable.  If you need 1,000 nodes you might be able to get away with it if very clever (multiple identities, careful IP proxying, camouflaged instances, etc).  More than that EC2 is a dead end.

Probably not.  Just because 200K BTC trades ON the MtGox exchange (which has nothing to do with the blockchain) doesn't mean an attacker could profit from all that.

So an attacker has a large number of BTC.  He deposits it on MtGox and then starts building an "attack chain" in secret.  Even if he converted the 200K into $2M he can't withdraw that in a day.  Tier 3 verification (requires requires an apostle seal from your state govt for US residents) is still limited to $100K per day ($500K per month).  So an attacker "could" in theory profit $500K in 5 days.  Of course that ignores the effect of an additional 50K BTC in selling pressure driving down the price.

However in 5 days an honest miner could generate $225,000.  So the ratio between good and bad is much smaller.  Also the only way you are moving $500K in 5 days is by bank wire which is going to leave a trail.  So $225K honestly or $500K + $225K = $725K and risk of going to prison?  Factor in some delays by MtGox on wires and it may require more like 10 days to ensure you have sufficient funds which makes the attack more like $450K honestly or $950K + prison.  Worse say there is a mixup or an AML/KYC hold by one of the banks for 15 days.  Ouch more and more hashing power just to get this "easy" $500K.

Of course even if successful you are now a wanted man and likely wouldn't get more than one attack.  Next month if you tried again (even with a new account) MtGox likely would have lower limits or more stiff validation so it is a low return of then $20M or so you spent on hardware.  Plus nobody is going to run a 10TH/s farm by themselves you are talking an entire crew (admin, technical, electricians, security - you weren't going to leave $20M unguarded in some warehouse were you).  Seems a pittifully small "score" divided 5? 10? ways to risk prison. 

Much easier to just offer 7% returns and have people hand you 10x as much with no strings attached.

Satoshi designed it well.  The economic disincentive for doing the wrong thing makes it very unlikely there will ever be an economically viable 51% attack.  The only real threat is a non-economic 51% attack (where the attacker sees the attack as simply an unrecoverable cost to destroy Bitcoin).

It may not be possible to buy 108,000 of these products. 108,000 of them may not even exist.

Since we're bringing things back from the dead:

Assuming 200,000 btc trade hands at lets say an average of $10, (just at mtgox) thats 2 million per day, with mining costs of 11,000 per day. Is this not a favourable ratio?

Yes, but using Nvidia cards for that is retarded. ATI is much much much better. But well, if you want to use something simple like Amazon EC2 instead of setting up hundreds of rigs with ATI cards maybe it's fine.

Please correct me if I'm wrong,

Currently the network hashrate is 17.35. Amazon EC2 has a product that have 2 x NVIDIA Tesla M2050 GPUs. This have a combined power of 160Mhash/s. 17,350,000 / 160 = 108,000 instances to achieve 51% attack.

So 108,000 * 2.10 = $226,800 / hour to achieve 51% attack. Is my calculations correct?

I think we ought to ask BCX as he has threatened and actually done many a 51% attacks :

-NMC threatened and got 30 000 NMC ransom
-FBX killed off by him
-SLC threatened but failed

I think I am missing another one here too.

Ask altcoin attackers.

Yes and that is a powerful disincentive.  Also getting away with widespread fraud will leave trails in meatspace and that likely will get the attacker caught.  I believe the risk of an economic 51% attack is highly improbable.  As economic activity increases, the value of BTC will increase and the value of the hashing power required to have 51% will also increase.  The network is essentially self-protecting.


Exactly.  The amount of time can vary but with 51% of hashing power it is a mathematical certainty that eventually the attacker will have a longer chain.  One thing to note is that the attacker can't go back in time.  Meaning if an attacker started now they could only affect future blocks.  Going back in time requires exponentially increasing hashing power because the attacker is essentially starting behind.

The attacker could generate blank blocks but it would create more destruction to create double spends even if the attacker doesn't benefit.  An attacker for example could place 10,000 orders at various Bitcoin merchants using names & addresses harvested via "win a free gold coin, free PS3, free ipad, etc" websites.  These patsies would simply exist to be destinations for merchants goods.  The attacker could then double spend the network reversing all those transactions and the merchants would be out hundreds of thousands of coins.  The resulting chaos would likely create a lot of negative press when merchants contact these "contest winners" asking for merchandise back.  Also remember when the transaction is reverse it also reverses any follow-on transactions.  Attack sends 100 BTC to you.  You pay me 20 BTC.  If attacker reverses his transaction it also reverses mine (as you never had the coins to pay me).  That creates further chaos as there is no a conflict between you and me. 

So even if the attacker has no economic gain using double spends would cause massive chaos and economic losses for participants.


It is unlikely it would require attacker continuing in perpetuity.  The reversal would wipe out all miner profits for those reversed blocks.  Imagine if every miner received 0 BTC income this month but still had hundred or even thousand dollar power bills.  Miners would quit in droves.  Merchants would stop accepting Bitcoin as fear of the reversability of transactions spread.  Bitcoin prices would crash and the attacker could profit by shorting or using put options to gain when Bitcoin prices decline.

However yes any good blocks will eventually be overwritten because the longest chain always wins.  So while in the first block the defenders (if they have 49% of hashing power) will have a 49% chance of being ahead the attacker will make the alternate chain in private.  If the defenders get lucky and get 2 or 3 blocks ahead he can simply restart at the current block attempting to win the next race.  Eventually the defenders luck will break and their chain will fall behind.  Once the attacker has a longer chain (with a solid lead that is improbable to overcome) and enough transactions ready to double spend he can broadcast the alternate chain, clients will replace the good blocks with bad and in doing so reverse all those transactions and render all other transactions unconfirmed.

DeathAndTaxes, you are making some interesting points!

The traditional scenario is the 51% attacker is using his hashing power to somehow directly profit. The disincentive in that scenario is that 51% hashing power will net more in mining than in double spends.

The scenario you describe is the 51% attacker is spending money to destroy bitcoin without a direct profit incentive (there incentive may be indirect like a competing monetary regime). With 51% or more of the hashing power the attacker will secretly mine for 1 day to two weeks then drop a new chain on the internet. This new chain will contain zero transactions, or non other than what directly benefits the attacker. The honest nodes will have a fresh pool of transactions to confirm and 49% or less chance to get the next block. Do honest blocks eventually get rejected because the attacker is able to perpetually rewrite the chain with empty blocks?

If what you mean is that the client will never switch to a different branch, even if longer, if it rejects a block which already has x confirmations, this will lead to situations where a node has checkpointed the wrong version and will never be convinced to switch to the true one. I'll call this approach (which isn't new, of course) "branch cementing".

My own ideas for synchronizable checkpoints - proof of stake via signature blocks - can be found here. In fact this can work in conjunction with block cementing, since a wrong cement will occasionally be overthrown by a signature block.