How exactly would a 51% attack work?

[pointbiz]

What I meant by blacklisting was not as elaborate as some have suggested. I merely meant to say that double spends can be easily detected. Once the address which has the proceeds of the double spend is detected then no one will accept payment from that address as good for a trade. Of course the transaction will be processed and received but the recipient will know (through monitoring the forums, etc) that the payment came from a blacklisted address. Merchants just need to keep a lookup table of bad addresses that is published by some trusted unofficial group.

Detecting the double spend should be easy. Address A(ttacker) sends money to Address B(ob) and Address C(on). Bob gets burnt and looks up Attacker's address in the block chain and see's the money went to Con and announces that no one should accept payment from Con, the 51% attacker.

[1714063295]

1714063295

[1714063295]

1714063295

[1714063295]

1714063295

[pointbiz]

I'm glad no one is worried about a 51% attack being used to perform a double spend.

Everyone is still worried about a 51% attacked being used as FUD. That brings a question to mind, how would we stop a 90% attack? If we can't then what's the difference in worrying about a 51% attack versus a 90% attack? Other than 39%

[DeathAndTaxes]

What I meant by blacklisting was not as elaborate as some have suggested. I merely meant to say that double spends can be easily detected. Once the address which has the proceeds of the double spend is detected then no one will accept payment from that address as good for a trade. Of course the transaction will be processed and received but the recipient will know (through monitoring the forums, etc) that the payment came from a blacklisted address. Merchants just need to keep a lookup table of bad addresses that is published by some trusted unofficial group.

Nobody would be foolish enough to keep extra funds in the address they double spent from.

I transfer 1000 BTC in Address X.
I spend those 1000 BTC on GPU from Alice.
I publish the 51% attack chain (built in private) reversing that transaction.
I spend 1000 BTC on gold coins from Bob.
I delete address X from my private keys because it has 0 balance.

What good does "blacklisting" address X do?

Detecting the double spend should be easy. Address A(ttacker) sends money to Address B(ob) and Address C(on). Bob gets burnt and looks up Attacker's address in the block chain and see's the money went to Con and announces that no one should accept payment from Con, the 51% attacker.

Detecting a double spend after the fact is both easy and useless.  It is likely detecting if a bank has been robbed by checking to see if the vault is empty when you open it.  In your example there what happens if money has already been transferred from C(on) to P(atsie).  Patsie loses her funds because she was the 2nd half of the victims in the double spend attack?

There is no way to know if address P is owned by the attacker, an accomplice, or a third party victim.  Also there is no concept of "a bitcoin" just balances of addresses. 

So attacker transfers 1000 BTC from address C(on) into address X.
He also transferred 1000 BTC from address L(egit).
He never uses address C again so blacklisting it is useless.

Are you going to also blacklist address X which may or may not be controlled by the attacker?  Are you going to blacklist all 2000 coins even though only half of them are were derivitives of the double spend?

[cbeast]

I'm glad no one is worried about a 51% attack being used to perform a double spend.

Everyone is still worried about a 51% attacked being used as FUD. That brings a question to mind, how would we stop a 90% attack? If we can't then what's the difference in worrying about a 51% attack versus a 90% attack? Other than 39%

Right, a 51% attack would only benefit the attacker if someone was dumb enough to trust them with a large transaction. I doubt they would bother with a small transaction. Rather than 'blacklisting' addresses it is simple enough to 'whitelist' or rather 'greenlist' addresses from trusted sources for larger transactions.

[DeathAndTaxes]

Right, a 51% attack would only benefit the attacker if someone was dumb enough to trust them with a large transaction. I doubt they would bother with a small transaction. Rather than 'blacklisting' addresses it is simple enough to 'whitelist' or rather 'greenlist' addresses from trusted sources for larger transactions.

51% = 100% control over blockchain.

Why try steal 1M BTC when you can steal 100 BTC per transaction over 10,000 transactions?  You going to whitelist every transaction big or small from now till the end of time?

[DeathAndTaxes]

I'm glad no one is worried about a 51% attack being used to perform a double spend.

Everyone is still worried about a 51% attacked being used as FUD. That brings a question to mind, how would we stop a 90% attack? If we can't then what's the difference in worrying about a 51% attack versus a 90% attack? Other than 39%

51% = 100% chance over overcoming the legit chain.  No attacker needs 90%.  They just need 51% and enough time.  While an attacker may use more hashing power to execute the attack quicker it isn't necessary. 

[cbeast]

Right, a 51% attack would only benefit the attacker if someone was dumb enough to trust them with a large transaction. I doubt they would bother with a small transaction. Rather than 'blacklisting' addresses it is simple enough to 'whitelist' or rather 'greenlist' addresses from trusted sources for larger transactions.

51% = 100% control over blockchain.

Why try steal 1M BTC when you can steal 100 BTC per transaction over 10,000 transactions?  You going to whitelist every transaction big or small from now till the end of time?

There's enough variance that an attacker will not be able to sustain an attack indefinitely with only 51%. This has been discussed ad nauseum. Besides, whitelisting can be automated so it may someday become the norm, at least for large transactions.

[DeathAndTaxes]

Right, a 51% attack would only benefit the attacker if someone was dumb enough to trust them with a large transaction. I doubt they would bother with a small transaction. Rather than 'blacklisting' addresses it is simple enough to 'whitelist' or rather 'greenlist' addresses from trusted sources for larger transactions.

51% = 100% control over blockchain.

Why try steal 1M BTC when you can steal 100 BTC per transaction over 10,000 transactions?  You going to whitelist every transaction big or small from now till the end of time?

There's enough variance that an attacker will not be able to sustain an attack indefinitely with only 51%. This has been discussed ad nauseum. Besides, whitelisting can be automated so it may someday become the norm, at least for large transactions.

Once again with 51% (or whatever comfortable margin you feel is necessary) whitelisting is useless.  Why reverse a single 1M transaction when you can just as easily reverse 10,000 100BTC transactions. 

With 55% hashing power the attacker has a 99.99% chance of having longest chain after 340 blocks.  With 60% hashing power is it only 89 blocks to give the defenders less than 1 in 1000 chance of preventing a reversal.  With 52% of hashing power just jumps to 700 blocks and with 51% it is 2411 blocks. 

Not sure where you get the idea that can attacker couldn't sustain the attack.  Most of the cost would be an capital expenditure once spent the ongoing electrical cost would be modest.  340 blocks is <3 days.  Even 2411 blocks is <16 days.

[cbeast]

Right, a 51% attack would only benefit the attacker if someone was dumb enough to trust them with a large transaction. I doubt they would bother with a small transaction. Rather than 'blacklisting' addresses it is simple enough to 'whitelist' or rather 'greenlist' addresses from trusted sources for larger transactions.

51% = 100% control over blockchain.

Why try steal 1M BTC when you can steal 100 BTC per transaction over 10,000 transactions?  You going to whitelist every transaction big or small from now till the end of time?

There's enough variance that an attacker will not be able to sustain an attack indefinitely with only 51%. This has been discussed ad nauseum. Besides, whitelisting can be automated so it may someday become the norm, at least for large transactions.

Once again with 51% (or whatever comfortable margin you feel is necessary) whitelisting is useless.  Why reverse a single 1M transaction when you can just as easily reverse 10,000 100BTC transactions. 

With 55% hashing power the attacker has a 99.99% chance of having longest chain after 340 blocks.  With 60% hashing power is it only 89 blocks to give the defenders less than 1 in 1000 chance of preventing a reversal.  With 52% of hashing power just jumps to 700 blocks and with 51% it is 2411 blocks. 

Not sure where you get the idea that can attacker couldn't sustain the attack.  Most of the cost would be an capital expenditure once spent the ongoing electrical cost would be modest.  340 blocks is <3 days.  Even 2411 blocks is <16 days.

It will be interesting to see how a 51% attack actually plays out. It's all theory for the moment. It would take a large entity to do this, but there is more than one large entity out there. Probably several. If they were discovered, it's doubtful that their identity would remain unknown and there would be offline repercussions. On that note, Casascius has even shown that Bitcoin can be traded offline entirely if necessary. If there are ever Bitcoin Network wars unleashed by the major superpowers, we may be conscripted to fire up our GPUs to fight.

[Meni Rosenfeld]

The blockchain should have checkpoints every X blocks to limit the time the attacker has to act.  Then if you wait 2x blocks you should be pretty safe.  Blocks 1 to x are checkpointed by block x+1, which itself will be checkpointed by block 2x+1.

I think the bitcoin client already does this.

There are manual checkpoints hardcoded with each release.  I'm proposing a much higher frequency of checkpoints.

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.

[pointbiz]

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?

[DeathAndTaxes]

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.

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.

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.

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.

This new chain will contain zero transactions, or non other than what directly benefits the attacker.

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.

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?

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.

[finway]

Ask altcoin attackers.

[bulanula]

Ask altcoin attackers.

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.

[skinturtle]

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?

[Gabi]

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.

[fivemileshigh]

Subsidy or not the cost is real.  At this point there is no economic demand for an 8TH network.  Maybe not even enough for a 1 TH network.  The current network (at a guesstimate of 2MH/W, $0.10 per kWh and $1 per MH capital cost) consumes nearly $10,000 daily in electrical power and burns through another $1000 in depreciating hardware).  That simply isn't sustainable given the tiny amount of economic activity actually occurring.  

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?

[barbarousrelic]

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?

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

[DeathAndTaxes]

Subsidy or not the cost is real.  At this point there is no economic demand for an 8TH network.  Maybe not even enough for a 1 TH network.  The current network (at a guesstimate of 2MH/W, $0.10 per kWh and $1 per MH capital cost) consumes nearly $10,000 daily in electrical power and burns through another $1000 in depreciating hardware).  That simply isn't sustainable given the tiny amount of economic activity actually occurring. 

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?

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).

[DeathAndTaxes]

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

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.