These numbers are true, there is one thing to keep in mind: Any attempt to do so *is* visible to miners. The second a pool tries to start a fork and reverse a transaction, miners can see the prevblockhash on the pool no longer matches the main bitcoin network. While this isn't unusual in the case of an orphan race, the only time it has ever happened for more than 2 blocks in a row that I can recall was when we had a hardfork starting.
It's visible only in a purely abstract way. Deepbit was frequently "eating its own tail" due to running multiple bitcoin daemons which would end up on competing forks and then load balancing miners between them (if it doesn't do this anymore its only because it doesn't solve enough blocks).
Not a single person in the world noticed this until Luke-Jr, bless his occasionally trolly heart, added code to BFGMiner to refuse to mine when a pool appeared to be forking itself. But not many people run that code.
Moreover, it's only a very partial solution: Say the network is on block A, you don't include the transaction you want to conflict in A. Then then another miner solves A and the network moves on to A+1 but you stay on A. Eventually you solve A'+1+1+1 ... and with some luck reverse the transaction. Miners never see any self-forking, and so the protection in BFGminer cannot help.
Performing the attack in this way simply constrains when you can start the attack (only right after another pool found a block), it does not reduce the success rate.
Additionally, an unsuccessful attempt would be completely apparent to miner's because their earnings would plummet [unless the pool continued to pay miners for the fork blocks]. Since BTC Guild's earnings can be audited down to the block hashes that generated payouts, this would be obviously false due to the blocks that were paid not existing on the blockchain.
A number of years ago your pool delivered earning of something like 40% of expectations for months. A number of people were convinced that you were a thief because of it (that something was subtly broken, or there was some witholding attack seems like a more likely explanation, in my view), but that hasn't inhibited you from having the largest pool by far.
I cannot believe that many people would notice or care about a decline in revenue on the timescale of a single day or two.
Maybe they would. But thats a big maybe to stake the future of Bitcoin on, especially with people trying to open up new markets that allow them to take short positions. A substantial successful attack would dramatically undermine confidence in Bitcoin: The existence of major hashpower consolations already defeats the security assumptions, but its a theoretical weakness and until an attack happens many don't believe what incredibly shaky ground we are on here.
BTC Guild is gaining on % of the network again, and I've stated in the past I think this is something that will always happen. A zero-sum method of earning Bitcoins will always lead to natural monopolies as people prefer to get a steady income over a lottery.
Control over mining is orthogonal with pooling payments. There is no reason that a pool couldn't simply hand out coinbase transactions to miners and credit them for any remotely sane looking shares that includes the requested coinbase transaction. The pool would then only be a consolidation of miners payments and would have no risk for consolidating control of the blockchain consensus. Miners would become miners again, and not just people selling computing services for coin.
The risk that miners would intentionally have some junk transactions that get blocks orphaned would be strictly less than the block withholding risk which cannot be eliminated, as you could still ask miners to occasionally send whole blocks.
Had Satoshi though of this in 2010 I believe we would have a very different world today.
