it means that in order to double spend, you would have to be able to compute 2 blocks (containing your double spend) before the rest of the network is able to compute 2 blocks
No. Even if the network gets one block between your two blocks, you refuse to build onto that block: you build only onto your blocks. Since you are a little faster than the real network, you can prevent all other blocks from appearing in your chain, which is the longest.
Ah, I see now. If you compute the next two blocks faster than the rest of the network, the chances are still 50/50 whether you can compute the next block faster than the rest of the network. But if you always build on your own blocks and not the shared blocks...on average, every other block created (by you or the network) will cause the entire network to oscillate between your block chain and the other block chain.
I was thinking the other day about the practice of encoding a block into the client (that basically fixates the chain as of some block in the recent past)...perhaps that should be codified in the client to happen in some way automatically...set a limit of say 60 blocks and make it so the client's will not accept any chain that alters a block that's more than 60 blocks old. If someone were really paranoid about a transaction, they could wait 60 blocks (around 6 hours on average) for confirmation. I'm guessing there's a downside to this, but I'm too exhausted to think through it at the moment.
Edit: One other thought...something like this might be useful for garnering transaction fees. If you have this 60 block rule for firm embedding of the block chain...anyone needing rock solid confirmation within 6 hours would have an incentive to pay a fee with that transaction to ensure it gets included in the next block or two so they then only need to wait ~6 hours. If they don't pay a fee and it takes a couple hours for the transaction to get into a block, they could be waiting 8 or more hours.