A 0-conf double spend caused by FSS-RBF would be harmless since the original output (address and amounts) remain in the double spending trx. 

So all a merchant would need to do is monitor  block inclusion for the relevant output. Addition of some wallet logic would resolve it easily.

Technically the only difference is that a FSS-RBF requires an additional input trx to be included in the second trx. 

Not clear to me, why the limitation of adding an additional input hinders the added value of FullRBF and how significant that hinderance is. 

On Tue, 13 Dec 2022 at 11:59 John Carvalho <john@synonym.to> wrote:

Why wasn't this solution put in place back then? Are there problems with the design?

While I still think there are unhealthy side-effects of Full-RBF (like more doublespending at unknowing merchants, after years of FSS protection) I think discussion of this FSS-RBF feature is worth considering.

--

John Carvalho

CEO, Synonym.to

On Tue, Dec 13, 2022 at 8:09 AM Daniel Lipshitz <daniel@gap600.com> wrote:

Thank you for bringing that to my attention, apologies for not being aware of it.

First-seen-safe replace-by-fee as detailed here https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html  by Peter Todd  seems to be a very suitable option and route which balances FullRBF while retaining  the significant 0-conf use case.

This would seem like a good way forward.

________________________________

On Tue, Dec 13, 2022 at 6:20 AM Yuval Kogman <nothingmuch@woobling.org> wrote:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html

--

________________________________
Daniel Lipshitz
GAP600
www.Gap600.com

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev