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