📅 Original date posted:2022-12-14
📝 Original message:NACK
support for 0-conf is harmful for reasons already stated ad nauseum
On Wed, Dec 14, 2022 at 4:58 AM Daniel Lipshitz via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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 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
>>>>
>>> --
> ________________________________
> Daniel Lipshitz
> GAP600
> www.Gap600.com
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221214/5b534adb/attachment-0001.html>;
Erik Aronesty [ARCHIVE] /
npub1y2…5taj0
2023-06-07 23:17:47
in reply to nevent1q…jur6
Author Public Key
npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0Published at
2023-06-07 23:17:47Event JSON
{
"id": "130a7de463b785e0a5f00462f9c3b55b1e9a5b5589abe7557439c093102f0e3c",
"pubkey": "22944ce1e29904e3826d25013a614e4665693ec514003efacc1b7586e8e5d0aa",
"created_at": 1686179867,
"kind": 1,
"tags": [
[
"e",
"25f605421c4fbd232e596dae47a53ef1bea24a0bb884796971a01a9714ed6f81",
"",
"root"
],
[
"e",
"c0a6df3fdb0716f5fcbc763363560da8369d187233823981b1a0213a4f9d248a",
"",
"reply"
],
[
"p",
"597ddb53eb981ecf2a6caca109ddcf48de5e99c06614fd2a324b66c1f65dcfa6"
]
],
"content": "📅 Original date posted:2022-12-14\n📝 Original message:NACK\n\nsupport for 0-conf is harmful for reasons already stated ad nauseum\n\n\n\nOn Wed, Dec 14, 2022 at 4:58 AM Daniel Lipshitz via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e A 0-conf double spend caused by FSS-RBF would be harmless since the\n\u003e original output (address and amounts) remain in the double spending trx.\n\u003e\n\u003e So all a merchant would need to do is monitor block inclusion for the\n\u003e relevant output. Addition of some wallet logic would resolve it easily.\n\u003e\n\u003e Technically the only difference is that a FSS-RBF requires an additional\n\u003e input trx to be included in the second trx.\n\u003e\n\u003e Not clear to me, why the limitation of adding an additional input hinders\n\u003e the added value of FullRBF and how significant that hinderance is.\n\u003e\n\u003e\n\u003e\n\u003e On Tue, 13 Dec 2022 at 11:59 John Carvalho \u003cjohn at synonym.to\u003e wrote:\n\u003e\n\u003e\u003e Why wasn't this solution put in place back then? Are there problems with\n\u003e\u003e the design?\n\u003e\u003e\n\u003e\u003e While I still think there are unhealthy side-effects of Full-RBF (like\n\u003e\u003e more doublespending at unknowing merchants, after years of FSS protection)\n\u003e\u003e I think discussion of this FSS-RBF feature is worth considering.\n\u003e\u003e\n\u003e\u003e --\n\u003e\u003e John Carvalho\n\u003e\u003e CEO, Synonym.to \u003chttp://synonym.to/\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On Tue, Dec 13, 2022 at 8:09 AM Daniel Lipshitz \u003cdaniel at gap600.com\u003e\n\u003e\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e Thank you for bringing that to my attention, apologies for not being\n\u003e\u003e\u003e aware of it.\n\u003e\u003e\u003e\n\u003e\u003e\u003e First-seen-safe replace-by-fee as detailed here\n\u003e\u003e\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html\n\u003e\u003e\u003e by Peter Todd seems to be a very suitable option and route\n\u003e\u003e\u003e which balances FullRBF while retaining the significant 0-conf use case.\n\u003e\u003e\u003e\n\u003e\u003e\u003e This would seem like a good way forward.\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e ________________________________\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e On Tue, Dec 13, 2022 at 6:20 AM Yuval Kogman \u003cnothingmuch at woobling.org\u003e\n\u003e\u003e\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e --\n\u003e ________________________________\n\u003e Daniel Lipshitz\n\u003e GAP600\n\u003e www.Gap600.com\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221214/5b534adb/attachment-0001.html\u003e",
"sig": "c7c81c36f1e4095a2f0c5af6a1017aba8b43e01793eb3ca1977c11dcdb830045d8147f305da12e489c599146c41986fbe14c925ae67de689b4196690a4668d0e"
}