📅 Original date posted:2022-12-14 📝 Original message:A 0-conf double spend ...

Daniel Lipshitz [ARCHIVE] /

npub1t97…g2yy

2023-06-07 23:17:47

in reply to nevent1q…w8c0

📅 Original date posted:2022-12-14
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221214/aa2e6d65/attachment-0001.html>;

Author Public Key

npub1t97ak5ltnq0v72nv4jssnhw0fr09axwqvc20623jfdnvrajae7nqufg2yy

Show more details

Published at

2023-06-07 23:17:47

Kind type

1 Short Text Note

Event JSON

{ "id": "c0a6df3fdb0716f5fcbc763363560da8369d187233823981b1a0213a4f9d248a", "pubkey": "597ddb53eb981ecf2a6caca109ddcf48de5e99c06614fd2a324b66c1f65dcfa6", "created_at": 1686179867, "kind": 1, "tags": [ [ "e", "25f605421c4fbd232e596dae47a53ef1bea24a0bb884796971a01a9714ed6f81", "", "root" ], [ "e", "04a04dbfe2df1469bacf2a5aa8867bbb228abf742eb50e84db8c088267067a3c", "", "reply" ], [ "p", "597ddb53eb981ecf2a6caca109ddcf48de5e99c06614fd2a324b66c1f65dcfa6" ] ], "content": "📅 Original date posted:2022-12-14\n📝 Original message:A 0-conf double spend caused by FSS-RBF would be harmless since the\noriginal output (address and amounts) remain in the double spending trx.\n\nSo all a merchant would need to do is monitor block inclusion for the\nrelevant output. Addition of some wallet logic would resolve it easily.\n\nTechnically the only difference is that a FSS-RBF requires an additional\ninput trx to be included in the second trx.\n\nNot clear to me, why the limitation of adding an additional input hinders\nthe added value of FullRBF and how significant that hinderance is.\n\n\n\nOn Tue, 13 Dec 2022 at 11:59 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________________________________\nDaniel Lipshitz\nGAP600\nwww.Gap600.com\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221214/aa2e6d65/attachment-0001.html\u003e", "sig": "78629c1082ab455c386a7a4412d7bf44293e8125e00d5e21fe20de7773585998694081dbfe1f5e5438b89ae5218c61157ed59ada302d811df18eea9dedbcb678" }