Topic: How exactly would a 51% attack work? - page 2. (Read 19294 times)

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.

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.

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.

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. 

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?

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.

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 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?

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%

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.

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

I think the bitcoin client already does this.

  Not that I would, but I was bored and calculated it out using existing tech, cost of  space, servers, etc. And, I could do it for ~1.28mil per TH..... That's just cost, and has 0 to do with the value of that space, hardware, etc if used for something else. It simply is to state it CAN be done at that price and not how feasible it is or isn't...

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.

From what I understand, it would take way more than a few million bucks to have more than 50% of the network hashing power.

Subsiziding doesn't remove the cost it merely obfuscates it. That cost is felt in inflationary pressure.  If the economy only needs 1000 new BTC daily to satisfy growing demand (due to rising economic activity) and achieve stable prices, but instead generates 7200 via mining then the price of BTC relative to fiat will fall.   Another way to look at it is 7200 BTC daily reward @ $3 is a ~$20K daily expansion to the money supply.  If that expansion is unwarranted then price will fall.

So users of Bitcoin either pay the cost of the network (massively outsized compared to necessity) via direct cost (say a 8% transaction fee looking at volume vs hashing power) or they pay it indirectly via inflationary pressure on their currency.

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.  

Well, currently mining is subsidized by generation. But once that's over it's not at all obvious that the network hashrate (scaled to hardware advances) will be as high as it is now even if Bitcoin is successful, and the incentives of trillion-dollar entities to attack it become ever greater.

In another thread I estimated that it would be ~$2M per TH with COTS when you consider labor, electricity (including mains upgrades), warehouse space, racking, cooling, and administration.

However I personally believe the network is too large to be sustainable at this point.  In the medium term I expect hashing power of the network to continue to decline as there is insufficient real transaction volume to warrant the current network size.

I object to the idea that a "few million bucks" would place a person in control of mining capacity large enough to be 51% of the network.
Between video cards, computer hardware, networking equipment, furniture (server racks, etc.), cooling, OFFICE SPACE, labor, advertising to get that much labor, electricity, etc. it would have to be quite a chunk of change. A few million probably wouldn't do it.

Just take one of the items, "labor" for example -- we're not talking the kind of labor you can pick up outside Home Depot    PC techs make more than minimum wage, and the guy who can design and manage something of that scale (layout, cooling, connectivity, Linux expertise, etc.) is certainly going to make more than $10/hour.

That's my point -- the Bitcoin network is HUGE at this point, and to get 51% would take an operation of insane magnitude.

Besides, when NewEgg and everyone else is all the sudden "sold out" of 6XXX series cards, many Bitcoin advocates and miners would know something is up

1) You won't have any warning a 51% attack is in progress until after the fact.  The attacker will build an "attack chain" in private.  With 51% of the hashing power it is a mathematical certainty that eventually his chain will be longer than the legit chain at which point he publishes it and it rewrites the prior transaction.

2) Even if you did blacklist an address it is unlikely the entire mining community would do so by unanimously.  If there was a "blacklisted" address involved in a transaction with a 5% fee you honestly think no miner or mining pool would every accept that from now till the end of time?

3) Preventing blacklisting would be trivial.  You simply make sure the address never has more than the double spend.  i.e  I have address X w/ 10K BTC.  I double spend it via two transactions A (involving 10K BTC) and B (involving 10K BTC).  After the double spend is complete address X has a value of 0 BTC.  Given you can generate an infinite number of addresses for free what value is there is blacklisting an 0 value address?



I believe this is the most likely.  The huge cost of amassing that much hashing power means it would likely always be more profitable to use that hashing power for "good".  Getting away w/ double spend would be difficult because any shipped products (or transfered fiat) can be traced.  Even if the double spend could go untracable there is going to be meatspace trails. 

So IMHO the only reason to 51% the network is to kill it.  A currency has value only if its value can be trusted.  Bitcoins which can disappear at the will of an attacker have no value.  The collapsing price, falling hashrate, and reluctance of merchants to accept them after a 51% attack will kill Bitcoin.

You can reject all blocks which do not belong to you, to make sure you get 100% of the block reward rather than your hashrate proportion.

You can reject all blocks which do not belong to you and not include any transactions in your own blocks, to prevent any transaction from being confirmed.

Identifying addresses involved in double spending isn't trivial, especially if you consider that future advanced transaction schemes could make use of legitimately superseding one transaction by another.

Even if you could detect them, I for one disagree with the idea to blacklist addresses. And my own disagreement is indicative of the fact that it will be very difficult, if at all possible, to obtain consensus to do this, and even if so, the client software isn't set up for this and a lot of work would be required to enable this feature. Also, for this to work the entire network needs to agree which addresses are blacklisted which is also difficult, so you're guaranteed to have chaos.

The main misunderstanding is to think that the only reason to carry out a hashrate attack is to profit from a double-spend. More likely a hashrate attack will be carried out by someone who wants to destroy Bitcoin, or at least to profit from short-selling bitcoins. Generally, mechanisms to protect against profitable double spending will amplify the chaos that ensues during such an attack, making us more vulnerable to a malicious attack.

Also, once this starts happening the bitcoin rate will probably drop, and depending on the attack miners will have their blocks rejected so it won't be profitable. Miners will quit and then it will be even easier to continue the hashrate attack. And since the difficulty targeting algorithm doesn't handle sudden drops in hashrate well we have a whole new set of problems.

This is a problem which hasn't been solved yet. It is probably solvable, and I've written occasionally on some pieces of what I think the solution will be. And I'm sure you could respond with some additional protection mechanisms. But these all have their own pros and cons, and need to be carefully considered, agreed upon and implemented. We need to prepare in advance for the contingency of a hashrate attack. Otherwise the chaos of the event could radically shake the faith in Bitcoin.