Or we could just use twice as many GPU.

Just looking at the computing cost underestimates the true cost and complexity of such an attack. 8.5TH is roughly 12K HD 5970s or 20K HD 5870s.  Where are you going to put it them?  You need to consider building and other structural (racks, wiring, ducting, power distribution) costs.  

If assembled into 8 GPU rigs it would require assembling 2500 to 3000 computers.  Who is going to assemble them? Who is going to adminster them?  Who is going to construct racks, run the miles of networking cables, and build the power distribution circuits?  Who is going to guard them (don't want $7M in computers to walk away)?  You need to consider labor costs.

The farm will require roughly 5200 KW connection to the power grid.  A rather non-trivial tasks which requires expertise, planning w/ power company, and long term contracts.  You need to consider the permitting, inspection, and contract costs.

The farm will produce 13 million BTU of thermal output.  We are talking industrial grade cooling system (larger than used by even major datacenters) and likely a custom designed system to ensure the system can pull the heat out of the room quickly enough to avoid unsafe temps.  Remember you need even temps across 2500 rigs pull a KW or so each.  The cooling alone will contribute about 1200 KW of additional electrical load.  This isn't rig a box fan in front of the video card setup.  You need to consider the enterprise sized cooling costs.

The true cost in planning, construction, and execution is likely 3x higher.  Still your right it would be possible for a bank or rogue government to execute a non-economic 51% attack.

The bad news is that using CPUs wouldn't solve that problem. You have simply increased the cost of the network.  The network is specifically 8.5TH today because the value of Bitcoin supports a network that powerful.  We could make it 17TH by just using 2x as many GPU but we aren't 17TH because the revenue from the network doesn't support more that much computing power.   Using CPU doesn't change that dynamic.  The annual revenue wil simply be split between CPUs & GPUs and each sub portion of the network will be smaller.

Don't forget that GPUs are not the only way to contribute hashing to the network.  FPGAs really cut down dramatically on everything you mentioned in your counter-arguments.   Sure FPGAs are much more expensive material cost, but you avoid most of the problems above, or at least a couple orders of magnitude of such problems.  You're probably cutting down energy consumption and heat by a factor of 20.  And with a really creative setup, you can probably get many dozen FPGAs onto a single computer (especially since the bandwidth required between CPU and device is basically negligible).

Yes, still requires a lot of work, but probably an order of magnitude less work.

It doesn't have to be that complicated. You are thinking the adversary will create a dedicated mining facility, but it would be easier for them to use existing infrastructure. Large banks already have tens of thousands of computers. Some of them might be already powerful enough to mine, others can be upgraded with minimal costs - get any local contractor to drop decent GPUs in a few computers at every branch. These are already solved problems, upgrades and fixes are one email away. Administration is already solved, too. Mass deployment of a smart miner (I'm thinking cgminer) who can do everything automatically is simple enough (already existing procedures). A few more GPUs won't make a major impact on the local power grids, so no worries there either. All they need is to run their own pool and write the attack code. Large institutions already have people who could do that, too.

I dare say that any top bank can do a 51% attack with minimum hardware investment, plus the human resources cost and extra power consumption. It's not going to be cheap, of course, but nowhere near your calculations.

I have thought of one way the block chain could be defended in an attack...

I could start up a "Casascius Block Registry" by myself, which would be some RPC web service where I sign all the blocks that I think are good, and allow people to query me for my signature for any given block.  No one has to care, nor does anyone have to pay attention to what I'm doing, and more than likely, I get very few hits from only a few curious geeks.

A few other individuals who think alike might do the same thing.  So after all, you have a bunch of obscure geeks signing blocks, nobody cares about these signatures, nobody queries them.  Consider it a form of digital masturbation.  Maybe a dozen people do this.

Then along comes an attacker.  Panic ensues, along with widespread disagreement as to what to do next.

One option on the countermeasure table becomes to incorporate querying the "Casascius Block Registry" into clients, as well as the other dozen registries created the same way, as an assistive tool to decide which blocks are legitimate and which should be discarded.  This effectively puts the whole of Bitcoin into the hands of a dozen individuals, which of course is far from decentralized as Bitcoin would like to be, but would be better than the status quo in the event of an attack that experiences success.

By starting my registry long in advance, I would have already defined an RPC query protocol and established in people's minds that such a database exists as a countermeasure.  I'll have a sense of established legitimacy and reputation for having Bitcoin's best interest in mind, and by analyzing what I sign, people will have already had a sense for how I decide whether a block is good or bad before they point their clients at me as a source of validation for blocks.

If it successfully mitigates a 51% attack, others start to realize what a good idea it was, and start their own block registries so defensive power isn't in control of a dozen individuals for very long.  And if the attacker gives up and the registries aren't needed anymore, the world can go back to simply using the longest proof of work as is done now.

My registry wouldn't be of much use if I signed bogus blocks, because people would just unsubscribe from it, and because the other 11 (or n) operators probably aren't going to be signing the same bogus blocks, any manipulation I make would likely get outvoted by the others.  The network shouldn't ever grow "dependent" on my service - it need only have a spot where the user can pop in a URL to subscribe to block validity hints - the same way you can point a mail server at the antispam blacklist of your choice since they all have a similar DNS-based protocol.  My service would essentially be to offer a tiebreaker to choose the more legitimate of two competing blocks, each hint I sign would be open to scrutiny.  If I start publishing crap (for example, I am favoring a revision of a block that contains an obvious double spend against an earlier revision of that same block, or condemning a block with perfectly valid transactions, or am attempting to roll back several blocks at the same time without a flamingly obvious well-known good reason), people would see this, they would ignore me and go elsewhere for the same service.

I was working on user-defined checkpoints today-- command-line/bitcoin.conf (and maybe a RPC call) that just says "Add this block hash at this height as a checkpoint."

You and your 10 trusted friends could then run a little program that coordinated automatic lock-ins whenever you like...

The only people that would matter the most are those who are mining, because the point of my service would be to hint which of two competing block chains to prefer in the event of a conflict/chain reorg, both of which would have to be credible (in the sense that they meet the difficulty requirements).  Most people aren't solo mining, they don't count for much.  I think even a minor chain reorg that contained a double spend conflict would already catch someone's attention today, somewhere.  News would spread fast.  I would have to do is alienate a few pool operators, and I'd be history, the same way if I started selling bogus Casascius coins.

Let's just say I was totally rogue, and I signed whatever the hell I pleased.  As long as I only signed one version of a block at any given height, and committed to always sign it within 4 blocks of having received it, it shouldn't really matter what I sign.  That's because to enable a double spend, I'd have to convince the network to discard a chain of at least 6 blocks (assuming that's the threshold for confirmation) and replace them with something better.  That's impossible if I'm committing to signing valid-looking blocks sooner as a condition of my signature stream being valid.

I would need to BE the adversary, or under the control of the adversary, to sign the wrong block stream.  And remember, no one would want or need to subscribe to my service during times of network peace - I'd only be a defensive countermeasure available to those who are actively fighting the attack.  Assuming I did a good honest job, others would see the value of making my service redundant, and then the assumption that 11+ other people might be doing the same thing for the good of the network wouldn't seem so silly as someone suggested.

what?

I think your understanding of block singing and network validation is flawed.  In a 51% attacker miners are irrelivent.  The attacker has more hashing power than all legit miners.  It isn't an issue of good miners being "confused" and continuing the bad chain.  Their actions are utterly irrelivent.  The double spend will happen in a matter of seconds or minutes.


The attacker will build a private block chain and not release it until it is sufficiently longer than the good chain.  Instantly clients will recognize the logner chain as valid.  

The attacker wouldn't care what miners know or think they are irrelevant.  What CLIENTS know and think is what matters. If clients are relying on your service attackers would only need to disrupt it (though finger nail pulling or large bank accounts in the Caymans) for seconds.  The false chain will be PRE-MINED and bad blocks released in rapid succession which you will sign as valid.  Clients accept it and double spends are confirmed as good transactions.

What happens AFTER that is also irrelevant.  The damage is already done.


Exactly if necessary you would be under the control of the adversary or simply dead and your keys under their control.  Also this concept of a heroic ongoing war between good and evil isn't factually valid.  There will be absolutely no warning of a 51% attack until it has already happened.  The entire bad chain will hit the network simultaneously and be propogated in a matter of seconds.  There will be nothing to fight.  

I don't know what you & Casascius have in your minds exactly, but my understanding of the "checkpoint services" would be that they will provide ratings for each block: AAA, AA, A and so on. The big exchange like MtGox would run its own pool and its own block rating service. Then instead of the fixed "6 confirmations" to consider the transaction valid people would agree to make the conditions more involved, eg: transaction is valid when MtGox rates the block containing it at least A and Casascius at least AA and slush|TradeHill-conglomerated at least AAA. There wouldn't be a single point to attack. The attacks would result mostly in  delays of the settlement.

The most important metric would be when the block was received.  If I receive a block that tries to replace a block 6 or 10 or 100 blocks ago on the chain I already know about, and I have no reason to believe I've been segregated from the network at large, I'm not going to vouch for it.

By the way, I don't have to be the only person "signing" blocks.  If pools signed their own blocks, the signatures in the blocks themselves could also be taken into consideration as self-vouching, as the attacker is not going to be able to fake those signatures.

With respect to the argument that the attack chain could/would be built in secret... this is 100% correct.  If I were MtGox, I would probably program my bitcoind to simply shut down if it ever came across a need to reorganize 6 or more blocks, so that the desired reorganization results could be sorted out manually.  (in effect, this could already be accomplished with just a few lines of code, and the desired outcome signaled via another block checkpoint, just like what the namecoin exchange did when faced with a threat).