path: root/e2/a4de540e7bf3ba01eaadb17971c72c00bfb492

Return-Path: <daniel@gap600.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CF7ACC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 14 Dec 2022 08:12:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 9391A4017E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 14 Dec 2022 08:12:46 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 9391A4017E
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gap600.com header.i=@gap600.com
 header.a=rsa-sha256 header.s=google header.b=0Q1jrX8o
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id OKq-Fz7bLUy2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 14 Dec 2022 08:12:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org C2209400C8
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com
 [IPv6:2607:f8b0:4864:20::d2a])
 by smtp2.osuosl.org (Postfix) with ESMTPS id C2209400C8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 14 Dec 2022 08:12:42 +0000 (UTC)
Received: by mail-io1-xd2a.google.com with SMTP id z144so3035632iof.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 14 Dec 2022 00:12:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gap600.com; s=google;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=4WocVI/Suwfe3MXsh1JkB6q+RQd+vkjWoonbCTelF2s=;
 b=0Q1jrX8oImOLkZf+BOofLXNNbhoKiUZ5hBR9J+36A4wohrD3uC+cGxXwIsFnviuPVy
 ApOLNTUkH0vFdpuM8cebzn3UGg7aqCp+9JcLOgTvCaDDDfxXuhsW5aw1tN+a8QDOcKni
 h9M2MSqe22v2QogvGDPFRQSyBmhkfPeRfo4jTFl1CyHD+ZkPcxJHnaVO5HAYLarZIGBz
 Oz+S/rpWOakppjzLl1ZW+3SvC4m+D5UexMOBMisECes2Z7ci3D++B4c/jqJfnwCoDnZ7
 ZSGNjiIC2yFU97yiycn+y8Omg62H+wJ3C1ulw6h+BCMWM7lXDeSVez4QY53aEwTd86tK
 o8UQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=4WocVI/Suwfe3MXsh1JkB6q+RQd+vkjWoonbCTelF2s=;
 b=ZzeFz1BnhgVAnYz4ucNEfr5vOVTm5f5rqCv27QnNIdVG4fv+EIl6MU50+UzyR7FcZ4
 DGD5HMMJ+ELMEm+Ws8OlqNhyPBmksH+XrEAUUic7Fr34V4gKJC2DUbXer96QzPQByW4a
 Hz8PGufSyGtpzy04jwEvxYvVIqbjOIk5JFL71iOX3pNqLpyXY6BRdutja698KZRlVmyF
 k0RIOUsxYLz6f/0pJrRTHRoOMShuKOt2k4a+lhjRhBy895mQPnSatQ+76Wj4Php+NIFy
 waYIT1vhW0vtWeVeBxrb+TLW2szcvxeNs5L4xIcSwxjviycx/Ar8gJOab1j3PY+MbIlL
 F0Dg==
X-Gm-Message-State: ANoB5pkf1UUOtcq3lcpr0KSLhxeah8/7oEMtDyHRhDtUxkIMtEqI5bPD
 IPOxUCZrbgerTzNVhSeggHkfYO9Uriywt5Ffrlc9IA==
X-Google-Smtp-Source: AA0mqf68Wc6pCI4Mu80OBuAANh0dzQ9CzA9hnGxk0d+VYxttwxc5/85No+gEGZDdXwFops+avoylpNIfr3sM0KNw180=
X-Received: by 2002:a5d:9ecc:0:b0:6d9:c117:7a1c with SMTP id
 a12-20020a5d9ecc000000b006d9c1177a1cmr41051983ioe.187.1671005561547; Wed, 14
 Dec 2022 00:12:41 -0800 (PST)
MIME-Version: 1.0
References: <CACkWPs_F94t9Q8TfyYYGxQANUT78SWFGkTOh6qRwnt=6ct7aig@mail.gmail.com>
 <CAAQdECAspoRJRz7j1ubAe=Cen==AVF5bm-Q2=0TiKc7NtbU65A@mail.gmail.com>
 <CACkWPs_4pjTo50=S86KPEznBs0PU7rd30rBGHq2Q5=6n6hYMgQ@mail.gmail.com>
 <CAHTn92wH17Z+p5cFOLpzsVUuTf4-nZc7tOjQr+_xjSU5groa0Q@mail.gmail.com>
In-Reply-To: <CAHTn92wH17Z+p5cFOLpzsVUuTf4-nZc7tOjQr+_xjSU5groa0Q@mail.gmail.com>
From: Daniel Lipshitz <daniel@gap600.com>
Date: Wed, 14 Dec 2022 10:12:30 +0200
Message-ID: <CACkWPs9hxQ8jMcr+=SC--SWt61CwRC0oovvcA868PXxnFipuQA@mail.gmail.com>
To: John Carvalho <john@synonym.to>
Content-Type: multipart/alternative; boundary="000000000000ea074b05efc54c78"
X-Mailman-Approved-At: Wed, 14 Dec 2022 09:58:33 +0000
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf
 use case
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Dec 2022 08:12:47 -0000

--000000000000ea074b05efc54c78
Content-Type: text/plain; charset="UTF-8"

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

--000000000000ea074b05efc54c78
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">A 0-conf double spend caused by FSS-RBF would be harmless=
 since the original output (address and amounts) remain in the double spend=
ing trx.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">So all a =
merchant would need to do is monitor =C2=A0block inclusion for the relevant=
 output. Addition of some wallet logic would resolve it easily.</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">Technically the only difference is =
that a FSS-RBF requires an additional input trx to be included in the secon=
d trx.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">Not clear t=
o me, why the limitation of adding an additional input hinders the added va=
lue of FullRBF and how significant that hinderance is.=C2=A0</div><div dir=
=3D"auto"><br></div><div dir=3D"auto"><br></div><div><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, 13 Dec 2022 at 11:59=
 John Carvalho &lt;<a href=3D"mailto:john@synonym.to">john@synonym.to</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;=
border-left-color:rgb(204,204,204)"><div dir=3D"ltr">Why wasn&#39;t this so=
lution put in=C2=A0place back then? Are there problems with the design?<div=
><br></div><div>While I still think there are unhealthy side-effects of Ful=
l-RBF (like more doublespending at unknowing=C2=A0merchants, after years of=
 FSS protection) I think discussion of this FSS-RBF feature is worth consid=
ering.</div><div><br clear=3D"all"><div><div dir=3D"ltr" data-smartmail=3D"=
gmail_signature"><div dir=3D"ltr"><span style=3D"color:rgb(34,34,34)">--</s=
pan><br style=3D"color:rgb(34,34,34)"><div dir=3D"ltr" style=3D"color:rgb(3=
4,34,34)"><div dir=3D"ltr">John Carvalho</div><div dir=3D"ltr">CEO,=C2=A0<a=
 href=3D"http://synonym.to/" style=3D"color:rgb(17,85,204)" target=3D"_blan=
k">Synonym.to</a><br><div><font size=3D"1" style=3D"color:rgb(34,34,34)"><b=
r></font></div></div></div></div></div></div></div></div><br><div class=3D"=
gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Dec 13, 2022 at =
8:09 AM Daniel Lipshitz &lt;<a href=3D"mailto:daniel@gap600.com" target=3D"=
_blank">daniel@gap600.com</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir=
=3D"ltr">Thank you for bringing that to my attention, apologies for not bei=
ng aware of it.<div><br></div><div>First-seen-safe replace-by-fee as detail=
ed here=C2=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin=
-dev/2015-May/008248.html" rel=3D"noreferrer" target=3D"_blank">https://lis=
ts.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html</a>=C2=A0=
 by Peter Todd=C2=A0<span style=3D"white-space:pre-wrap;color:rgb(0,0,0)"> =
</span>seems to be a very suitable option and route which=C2=A0balances Ful=
lRBF while retaining=C2=A0 the significant=C2=A00-conf use case.</div><div>=
<br></div><div>This would seem like a good way forward.</div><div><br></div=
><div><br></div><div><br><div><div dir=3D"ltr"><div dir=3D"ltr"><div><div d=
ir=3D"ltr"><div style=3D"font-size:12.8px">________________________________=
</div><div style=3D"font-size:12.8px"><br></div><div style=3D"font-size:12.=
8px"><br></div></div></div></div></div></div></div></div><br><div class=3D"=
gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Dec 13, 2022 at =
6:20 AM Yuval Kogman &lt;<a href=3D"mailto:nothingmuch@woobling.org" target=
=3D"_blank">nothingmuch@woobling.org</a>&gt; wrote:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204=
)"><a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-=
May/008248.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfo=
undation.org/pipermail/bitcoin-dev/2015-May/008248.html</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div></div>-- <br><div dir=3D"ltr" class=3D"gmail_signature" =
data-smartmail=3D"gmail_signature">________________________________<br>Dani=
el Lipshitz<br>GAP600<br><a href=3D"http://www.Gap600.com">www.Gap600.com</=
a><br><br><br></div>

--000000000000ea074b05efc54c78--