📅 Original date posted:2022-12-13
📝 Original message: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-fee
Those 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 Lipshitz
GAP600| www.gap600.com
Phone: +44 113 4900 117
Skype: daniellipshitz123
Twitter: @daniellipshitz
On Tue, Dec 13, 2022 at 11:59 AM John Carvalho <john at 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 <http://synonym.to/>;
>
>
> On Tue, Dec 13, 2022 at 8:09 AM Daniel Lipshitz <daniel at 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 at woobling.org>
>> wrote:
>>
>>>
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221213/6f6bc8d1/attachment-0001.html>;
Daniel Lipshitz [ARCHIVE] /
npub1t9…fg2yy
2023-06-07 23:17:43
in reply to nevent1q…3fff
Author Public Key
npub1t97ak5ltnq0v72nv4jssnhw0fr09axwqvc20623jfdnvrajae7nqufg2yyPublished at
2023-06-07 23:17:43Event JSON
{
"id": "5fc19799ce592e76c5eae37a3b82fa1c5bac52a0efe451dcb2b33d9826e540e1",
"pubkey": "597ddb53eb981ecf2a6caca109ddcf48de5e99c06614fd2a324b66c1f65dcfa6",
"created_at": 1686179863,
"kind": 1,
"tags": [
[
"e",
"25f605421c4fbd232e596dae47a53ef1bea24a0bb884796971a01a9714ed6f81",
"",
"root"
],
[
"e",
"6275ae5929df3a2862b7a4ee71b2fb6b2d9949d32dae547f7dc6ea6b7a009f41",
"",
"reply"
],
[
"p",
"02283afe5d7e6355ba7a0c2f5283e3149f651dab319cfb553d46a1d180234ed5"
]
],
"content": "📅 Original date posted:2022-12-13\n📝 Original message:I dont think there was anything technical with the implementation and as\nfar as I can tell this is well developed and ready.\n\nThe reasons I can find for not being adopted are listed here -\nhttps://bitcoincore.org/en/faq/optin_rbf/ under - Why not First-seen-safe\nReplace-by-fee\n\n Those reasons do not seem pertinent here - given OptinRBF already exists\nas an option and the added benefit of continuing to be able to support\n0-conf.\n\n________________________________\n\nDaniel Lipshitz\nGAP600| www.gap600.com\nPhone: +44 113 4900 117\nSkype: daniellipshitz123\nTwitter: @daniellipshitz\n\n\nOn Tue, Dec 13, 2022 at 11:59 AM John Carvalho \u003cjohn at synonym.to\u003e wrote:\n\n\u003e Why wasn't this solution put in place back then? Are there problems with\n\u003e the design?\n\u003e\n\u003e While I still think there are unhealthy side-effects of Full-RBF (like\n\u003e more doublespending at unknowing merchants, after years of FSS protection)\n\u003e I think discussion of this FSS-RBF feature is worth considering.\n\u003e\n\u003e --\n\u003e John Carvalho\n\u003e CEO, Synonym.to \u003chttp://synonym.to/\u003e\n\u003e\n\u003e\n\u003e On Tue, Dec 13, 2022 at 8:09 AM Daniel Lipshitz \u003cdaniel at gap600.com\u003e wrote:\n\u003e\n\u003e\u003e Thank you for bringing that to my attention, apologies for not being\n\u003e\u003e aware of it.\n\u003e\u003e\n\u003e\u003e First-seen-safe replace-by-fee as detailed here\n\u003e\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html\n\u003e\u003e by Peter Todd seems to be a very suitable option and route\n\u003e\u003e which balances FullRBF while retaining the significant 0-conf use case.\n\u003e\u003e\n\u003e\u003e This would seem like a good way forward.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ________________________________\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On Tue, Dec 13, 2022 at 6:20 AM Yuval Kogman \u003cnothingmuch at woobling.org\u003e\n\u003e\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html\n\u003e\u003e\u003e\n\u003e\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221213/6f6bc8d1/attachment-0001.html\u003e",
"sig": "30cf6c59a78fe6b6ee69271cf761f8c20a94e414d8a5bfed93fb24b42978b01adb5e83511ef6152af67fffba100d569784091abde8a4b5665db7373f4deec3ee"
}