Quote from: pawel7777 on December 09, 2015, 11:45:17 PM

Nice summary by Chris Pacia in this blog post:

https://chrispacia.wordpress.com/2015/11/29/on-zero-confirmation-transactions/

This article sounds a bit biased. E.g. it says:

Quote

retailers will be able to detect unconfirmed RBF transactions and reject them

But there is no need to "reject", you just don't process these transactions until you have some confirmations. Users that "opt-in" on RBF might have to wait longer in some situations.

I still wonder how this is supposed to be handled on the sender user interface - it seems very difficult to explain the implications to a normal user ("click here so your transaction is less likely to get stuck in the network but more likely to be delayed on the recipient side"?)

FSS-RBF certainly is a better solution from a user perspective even if it is less elegant protocol wise. Maybe it will also be added at some point. Or the awesome "Delayed-RBF" solution in the OP Cheesy

edit: btw is it only me that considers the use case for RBF of "Paying multiple recipients in succession" pretty irrelevant? Currently this is simply done by batching transactions so the practical cost savings will be minimal.