Some wallets like Electrum would be affected by that because they use RBF to batch transactions so, outputs cannot be exactly the same as before.On Tue, Dec 13, 2022 at 10:09 AM Daniel Lipshitz via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:I dont think there was anything technical with the implementation and as far as I can tell this is well developed and ready.The reasons I can find for not being adopted are listed here - https://bitcoincore.org/en/faq/optin_rbf/ under - Why not First-seen-safe Replace-by-feeThose reasons do not seem pertinent here - given OptinRBF already exists as an option and the added benefit of continuing to be able to support 0-conf.________________________________Daniel LipshitzGAP600| www.gap600.comPhone: +44 113 4900 117Skype: daniellipshitz123Twitter: @daniellipshitzOn Tue, Dec 13, 2022 at 11:59 AM 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.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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev