From: Daniel Lipshitz <daniel@gap600•com>
To: John Carvalho <john@synonym•to>
Cc: bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case
Date: Wed, 14 Dec 2022 10:12:30 +0200 [thread overview]
Message-ID: <CACkWPs9hxQ8jMcr+=SC--SWt61CwRC0oovvcA868PXxnFipuQA@mail.gmail.com> (raw)
In-Reply-To: <CAHTn92wH17Z+p5cFOLpzsVUuTf4-nZc7tOjQr+_xjSU5groa0Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1786 bytes --]
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 <http://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
[-- Attachment #2: Type: text/html, Size: 4075 bytes --]
next prev parent reply other threads:[~2022-12-14 8:12 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-11 20:24 Daniel Lipshitz
2022-12-13 4:20 ` Yuval Kogman
2022-12-13 8:08 ` Daniel Lipshitz
2022-12-13 9:59 ` John Carvalho
2022-12-13 11:33 ` Daniel Lipshitz
2022-12-13 14:00 ` Lucas Ontivero
2022-12-13 14:08 ` Daniel Lipshitz
2022-12-13 21:41 ` Peter Todd
2022-12-13 21:58 ` Daniel Lipshitz
2022-12-16 21:14 ` Peter Todd
2022-12-18 8:06 ` Daniel Lipshitz
2023-01-13 23:53 ` Peter Todd
2023-01-14 20:15 ` Daniel Lipshitz
2023-01-16 10:19 ` Daniel Lipshitz
2023-01-17 17:07 ` Erik Aronesty
2023-01-17 17:27 ` Daniel Lipshitz
2023-02-04 16:27 ` Peter Todd
2023-02-06 12:08 ` Daniel Lipshitz
2022-12-14 8:12 ` Daniel Lipshitz [this message]
2022-12-14 17:41 ` Erik Aronesty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACkWPs9hxQ8jMcr+=SC--SWt61CwRC0oovvcA868PXxnFipuQA@mail.gmail.com' \
--to=daniel@gap600$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=john@synonym$(echo .)to \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox