The Bitcoin developers are well aware of this non-issue:
http://sourceforge.net/mailarchive/forum.php?thread_name=CAJHLa0MVrQN6hyuAsYNRJ2CV6fsPnAbRDSUQH%2Bn6jfKdMiFaLQ%40mail.gmail.com&forum_name=bitcoin-development Every change to Bitcoin that blocks some transactions from propagating for any reason, such as them being harmful to the network, has this effect.
Zero-conf transactions have never been safe. For instance as
pointed out on irc by Peter Todd because Elgius has 3.17% of the hashing power and blocks Satoshidice transactions you can profitably double-spend Satoshidice in principle, earning the different between the 3.17% hashing power and the Satoshidice 1.9% house edge each time. (actually doing so profitably is difficult however due to the
risk of ruin among other things) You can get an even better edge by identifying all the miners blocking Satoshidice transactions and submitting to all them simultaneously, and you can further improve upon that edge by identifying miners blocking other addresses as well such as the "correct horse battery staple" address that was used to spam the network.
Never mind that because Bitcoin does not implement double-spend detection the vast majority of clients would never know if you simply broadcast two conflicting transactions at once. In that case there is a 50:50 chance of the transaction to the merchant being mined. Blockchain.info even created a easy to use tool to automate doing this:
https://blockchain.info/create-double-spend (although it's hard to click both "send" buttons fast enough for it to work, it works better if you submit one transaction on your local bitcoin node)
However we
can make zero-confirmation transactions safe
without complex trusted identity systems, ironically by making it easier to double-spend. If we implement replace-by-fee nodes will always forward the transaction with the highest overall fee (including parents) even if it would double-spend a previous transaction. At first glance this appears to make double-spending trivial and zero-confirmation transactions useless, but in fact it enables a powerful counter-measure to an attempted double-spend: the merchant who was ripped off creates a subsequent transaction sending 100% of the funds to mining fees. All replace-by-fee miners will mine that transaction, rather than the one sending the funds back to the fraudster, and there is nothing the fraudster can do about it other than hope they get lucky and some one mines their double-spend before they hear about the counter spend. The transaction can also be constructed such that the payee pays slightly more in advance, with the merchant refunding the extra amount once the transaction confirms, to ensure that a double-spend will result in a net loss for the fraudster.
Peter Todd is working on writing better memory pool code that will enable this technology for safe zero-confirmation transactions, although he has told me it won't be ready for awhile due to the careful testing required, and it only makes zero-confirmation transactions safer in proportional to the miners who adopt replace-by-fee. (currently about 0.25% by my ad-hoc measurements) That said if a reasonably large fraction support it, simply asking for a risk deposit as mentioned above or some other insurance method is an adequate approach to deal with the % of miners who will ignore the counter-transaction.
It remains an open question as to whether or not the core developers accept the changes required for safe zero-confirmation transactions, Gregory Maxwell's comments on the idea are worth reading:
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02226.html
