i think this whole argument is upside down.

insurance only exists to protect against an unlikely event.  your whole argument is that this is a likely event.  insurance companies are extremely risk averse and like to deal with risks that are highly measurable and not likely to occur.  

this is a highly unmeasurable proposal in that how is one supposed to measure this hidden reserve hashing rate that is kept offline in case of an attack?  even if you could measure it then everyone would know as would the attacker.  then we're back to square one which is that the attacker would know precisely how much hashing rate to bring online to ensure success of the attack.

what is to prevent cheating via one insurance company bringing online a small amount of its hashing rate to scoop up whatever tx fees exist in the ongoing verification process?

this also is a form of centralization in that you discourage all smaller players from plugging in their new Butterfly's b/c you've artificially suppressed the tx fees and i would argue that we want lots of newbies plugging these units in to strengthen the network.

a visible open p2p large hashing rate as we have now seems to be working and acts as an effective deterrent.

the risk of a likely attack causing chaos and a systemic failure for a purposely weakened, stripped down hashing rate invites trouble.  no insurance company would take this risk.

you might be thinking of starting an insurance business yourself and this might be why you think it will work; i don't know.  but i don't think most ppl will buy in.

I personally expect an explosion in hashing power as more fpga and butterfly like units come online.  Who won't want to hedge the USD against a nice small form unit plugged into their PC at the side of their desk?

This will be very good for Bitcoin.

There still seems to be quite some confusion about some of the potential attacks to a bitcoin network where the vast majority of the hashing power is only used when an attack is detected.

To add some clarity, I’ll go through each attack independently.

Double Spending Attack

The ideal double spending attack involves:
1.   Making a transaction for another ‘hard’ asset; such as physical face-to-face transfer of cash.
2.   As soon as this transaction is complete, secretly mine a chain that spends the above coins to a different address.
3.   Once well-ahead of the publicly known chain, attack release the hidden chain and the network reorganises onto the more-ahead chain.

Now this attack seems pretty fool-proof, until you do the numbers.  If (for whatever reason, I’ll come to that later), the bitcoin network wants to quickly orphan the offending chain, it will do so.

Say that the attacker has 2x the base-load of the network, and waits for 6 blocks of the public chain before releasing.  This means that the attacker (on average) will have a 6-block lead against the rest of the network.
When this attacking chain is released, let’s say 100x the base load hashing power is used to orphan the chain.   When the attacker has completed block number 13, the other chain has just completed 50 blocks, and now has a 43 block lead.  This completely orphans the attacker’s chain.

Effects:
When quite a few attackers have ‘attempted’ to double spend, then quickly get squashed in the 1st or 2nd block after they release their chain, this will naturally ‘raze the barrier’  to attack while no significant continuous  hashing resources are being spent.  Attackers don’t attack ‘just for fun,’ but they attack to win.   If the attacker wants to double spend, and win; they and the network holds 100x hashing resources to defend an attack.  Any-individual attacker must also have 100x the hashing power to win.  (Of course they get a very trivial head-start, by starting the attack in private).

This will make attacks on the network rare.


Supply Blocking attack
(Please note, that this attack must be externally funded to the bitcoin economy, as an internal malicious attacker would never be able to recoup the resources used to conduct this attack from the bitcoin economy itself).

This attack involves having more than 51% of the hashing power of the network, and orphaning any block that doesn’t agree with the attackers goals.  (Be it to kill bitcoin, or force high transaction fees, or regulate bitcoin in some way).

One would do this now by:
1.   Judge how much hashing power there is on the network
2.   Halve that number, and put a bit more on for margin of error
3.   Turn on this hashing power, and orphan any block that doesn’t agree with your rules.

This attack is quite simple to do with the current network.  Also you can be virtually confident that your attack will success if the attacker gathers more than 75% of the current hashing power.

With dynamic hashing power, the base-load hashing power becomes irrelevant; the ‘maximum, sustainable’ hashing power becomes the important metric.

The attacker must ‘guess’ what amount of the dynamic hashing load is sustainable, by the network, gaining much more hashing power than this for a safety margin.  This brings both up the uncertainly of the attack, and the cost.

However, the network will not just say, ‘I’m getting tired now.’ It will become a big game of bluff.  If the attackers chain is orphaned by the network by a significant margin (say more than 2000 blocks), then the network may automatically ‘cement’ into the new chain.

Overall… The same security issues with this externally funded attack remain for either a static hashing load or a dynamic hashing load.  However the dynamic hashing load makes the uncertainties in attacking the network much higher as well as not wasting as much electricity when there is no attack happening.

Insurance companies are businesses first, insurance companies second. The goal of any for profit business is profit first, not necessarily to be risk averse. This means it's logical to provide tornado insurance in "tornado alley" or earthquake insurance in California; just calculate high enough premiums to ensure profitability. The question boils down to whether or not enough customers will agree to your fees. Given the opportunities/possibilities Bitcoin provides I think there would be some tolerance of rates.

Overall I think the OP is definitely on to something with "on call" surprise hashing capacity. I also think insurance companies might play a role. However, I think a more straightforward source is bitcoin banks, businesses, etc. - anyone with decent wealth having interest in seeing bitcoin succeed as the OP notes. There can be an understanding promoted people are encouraged to participate in such a concerted defense action.

The suggestion is people with decent wealth who presumably have no problem maintaining significant offline hashing capacity; this doesn't need to be most people.

The offline 51% (or really 101%) attack problem is preventable if we want it to be.  No insurance companies or outside complications needed.

No. Going from CPU to GPU mining was a ~50x increase in efficiency (0.1Mhash/J to 5Mhash/J). Going form GPU to FPGA (using Butterfly Labs' Bitforce Single as an example) was a ~2x increase in efficiency (to 10Mhash/J (~800Mhash@80W). This is simply because a GPU employs an ASIC, albeit not a mining-specific one. So an FPGA isn't that much of an advantage (when total system power is excluded).

No dedicated mining ASIC exists yet. Largecoin claims to have an sASIC unit ready in July that does ~200Mhash/J - a 20x increase in efficiency.

A SHA-256 ASIC already exists that does 500Mhash/J (a further 2.5x increase in efficiency).

So going from FPGA to true ASIC is more like a 50x increase in efficiency (the same as going from CPU to GPU).

Other than that, I don't think your suggestion will bring any benefits to the network. Why would it help the network that people have offline miners they can turn on at will? Why not always have them turned on? How will these people recover the costs of their equipment if it's turned off all the time? I think you have a genuine interest in making the network more secure, but I don't relying on people to waste large amounts of money is the solution.