path: root/c4/bc9a2c5bb70b24c56ac8a4fe5df0fde316bed7

Return-Path: <earonesty@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 8C889C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 17 Jan 2023 17:08:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 4FB8C60BD7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 17 Jan 2023 17:08:09 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 4FB8C60BD7
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=q32-com.20210112.gappssmtp.com
 header.i=@q32-com.20210112.gappssmtp.com header.a=rsa-sha256
 header.s=20210112 header.b=H73wadgv
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Level: 
X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_FILL_THIS_FORM_SHORT=0.01] autolearn=no autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id C9h6soOjcQhl
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 17 Jan 2023 17:08:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 5E76460B26
Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com
 [IPv6:2607:f8b0:4864:20::e2e])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 5E76460B26
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 17 Jan 2023 17:08:07 +0000 (UTC)
Received: by mail-vs1-xe2e.google.com with SMTP id t10so22289936vsr.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 17 Jan 2023 09:08:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=q32-com.20210112.gappssmtp.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=XvnJiGCX0MWwjgX0mlKG/LvoStnQdeFm2wERLTPpGMQ=;
 b=H73wadgvJ7RtlwWZrt9QsgcDbG2C+JGYWdCP3mP5ZVzpTtmILyzJwTkgRYlM/WEZm5
 KY1d9wZ4iOp1Z3SCpg+PPlLR3mNBPee7zmDlEZzJItQ2raWJ9Z8hpfeVD0ZEMoMgrD1S
 1YDWANsuTwM6uhrRuqlBGyLhjS8uN0kzpSfDmRxbxaoe36n0ghFmKe1SptbtYyQy05QG
 OzToIsU5O99ftrWlitDRqCFAE9k0nZO3FVWRUSn2aZt64tDny4+/deAVswBC2c2JF7Ux
 tT/vrLKrP+H/CRdJ37XUN1J443vXMdTBEqo/ZrlPaWYpgFLI+/p5O2UBjnvPukLHlJrs
 Po/A==
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=XvnJiGCX0MWwjgX0mlKG/LvoStnQdeFm2wERLTPpGMQ=;
 b=EVpqToASMqtBNA5yJyFf786berLg/Ix5NLZYgTghK3KPhYtG9MDDtsFi1h2EoRv42G
 8SOyT9k0PoDbFmJDfoBUKgdd3AWRDSNNPXSF2hLj63coP3ZJNufOHqjOxVG4flsXRXPT
 WefEv1Kmfm8dsgFAKdhELO19fZmK4Flyo7h14ikeRbzKSsClpju6rM2BI2mvt5YjUrUB
 ZQemmVVt6GcPUgYMhUSvH3opchERmxRb1eKXmjLC5ZGIsPUoeakpGkCdiJqAkfdDqYL6
 8KTtVpmYsqfSEiNtGXv7o8vn7L+g93GYdqrfOwWaHgbbEa7PKU6rg/FzSn2n6OJ8W7sk
 3Pqw==
X-Gm-Message-State: AFqh2krj9oVJzpvzVLHvpzpE9TTPWgAU+XMNFLGnfTH32EsFglXl3V8F
 DydBQu/HvRTI0mm20FwwhrzBGb8pFMqvF/SbKvvdD6Q=
X-Google-Smtp-Source: AMrXdXuzw9kycWr5Xc5sLuXFHj9IFQ7WWz63TDz7dpjYfqInWrqoEcVgbaUvF7noVm8YjvqptZEM7BFQTT10j3bubTY=
X-Received: by 2002:a67:eb55:0:b0:3c6:1372:61ad with SMTP id
 x21-20020a67eb55000000b003c6137261admr516035vso.17.1673975285933; Tue, 17 Jan
 2023 09:08:05 -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>
 <CACkWPs9VawCYt7maiNqzafkFnHTiGJQkXMT4VXQQcG-rE2TTNw@mail.gmail.com>
 <Y5jxmItJIpIUVY+x@petertodd.org>
 <CACkWPs_jSLDg3seON0uu=ri6iR9cytXo2MEPJ5PVeap+iDreeQ@mail.gmail.com>
 <Y5zfuVGpRGaknwaU@petertodd.org>
 <CACkWPs_6z7UyXzejTqjy=i+SkSz-76VdzZ20K1DzcVJxan_HZg@mail.gmail.com>
 <Y8HvCbBd5+pm8Uj2@petertodd.org>
 <CACkWPs_Nqm1663c1q8xHX=A0Gpa7m1kV_QX6t0s8uPOEh3WQLA@mail.gmail.com>
 <CACkWPs94npkm9b--vfAraoKxXK-2A0fgv-NBcyRHzSCASuO1Bw@mail.gmail.com>
In-Reply-To: <CACkWPs94npkm9b--vfAraoKxXK-2A0fgv-NBcyRHzSCASuO1Bw@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Tue, 17 Jan 2023 12:07:54 -0500
Message-ID: <CAJowKgK9VQ3bgZZnnmTBkhF8DFrv08ywEQEC5oTvXX66d=mkoQ@mail.gmail.com>
To: Daniel Lipshitz <daniel@gap600.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000047eeb805f278bebc"
X-Mailman-Approved-At: Tue, 17 Jan 2023 17:40:39 +0000
Cc: John Carvalho <john@synonym.to>
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: Tue, 17 Jan 2023 17:08:09 -0000

--00000000000047eeb805f278bebc
Content-Type: text/plain; charset="UTF-8"

> 0-conf on Bitcoin with its understood risks is a significant use case

and that use case doesn't change, at all, with full rbf.   the risk profile
will, likely, remain the same.   observation of the fee paid, history of
doing business with the customer, transaction size are all needed.

On Mon, Jan 16, 2023 at 1:50 PM Daniel Lipshitz via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Some further clarity on our unique trx hashes queried to our platform, our
> initial and followup numbers on unique trx hashes queried were not accurate
> - apologies. Bitcoin addresses queried and Usd value and unique were
> accurate. This is as a result of our platform viewing each queried bitcoin
> address as a transaction from our point of view.
>
>  November 2022
>   Total queried unique bitcoin address- circa 1.5m trxs
>   Unique Bitcoin trx hashes queried- circa 500k
>   USD value - circa 220m
>   December 2022
>    Total queried unique bitcoin address- circa 1.7m trxs
>    Unique Bitcoin trx hashes queried - circa 500k
>    USD value - circa 200m
>
> There are further merchants and service providers who enable 0-conf on
> Bitcoin who are not working via our platform - I do not know their numbers
> but believe they are significant. 0-conf on Bitcoin with its understood
> risks is a significant use case.
>
> For third party clarification please see
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html
> and
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021238.html
> ________________________________
>
> Daniel Lipshitz
> GAP600| www.gap600.com
>
>
>
>
> On Sat, Jan 14, 2023 at 10:15 PM Daniel Lipshitz <daniel@gap600.com>
> wrote:
>
>>
>>
>>
>> On Sat, Jan 14, 2023 at 1:53 AM Peter Todd <pete@petertodd.org> wrote:
>>
>>> On Sun, Dec 18, 2022 at 10:06:15AM +0200, Daniel Lipshitz wrote:
>>> > GAP600 is not a trxs processor or liquidity provider we service
>>> merchants,
>>> > payment processors & non-custodial liquidity providers - our service is
>>> > purely the 0-conf enabling our clients to accept 0-conf. Clients
>>> access our
>>> > service via API - sending us the Trx hash & output address. Our
>>> service is
>>> > not based on AML/KYC it is purely an analysis of the Bitcoin network.
>>>
>>> I checked and to sign up for your service, you ask for the name, phone
>>> number,
>>> email, and company name.
>>>
>>> That is an example of AML/KYC. By learning the tx hash and output
>>> address, you
>>> learn which addresses are associated with what real world entity is
>>> paying for
>>> your service. You learning that information for what you claim is ~10%
>>> of all
>>> transactions is a significant privacy concern. On that basiss alone, I
>>> would
>>> argue that full-rbf should be implemented specifically to destroy your
>>> business
>>> and stop the collection of that data.
>>>
>>> We have standard commercial information about the payment processors,
>> non custodial liquidity providers and merchants which become our clients -
>> we do not have any kyc/aml information or telephone number on who is
>> sending our clients the bitcoin for deposit.  For us these are just bitcoin
>> Trx which our clients choose to benefit from 0-conf deposit recognition.
>> Our service is provided via API with the only information our clients share
>> with us, regarding a specific bitcoin transaction, being public bitcoin
>> information like trx hash and output address.
>>
>> > I am not at liberty to share names of other services which have
>>> developed
>>> > their own 0-conf service - they include a payment processor on a
>>> gambling
>>> > platform which services multiple gambling operators, a standalone
>>> gaming
>>> > payment processor, and a payment processor recently I have come
>>> across. We
>>> > also do not have a significant presence in Asia - so I don't have
>>> > visibility there.
>>>
>>> No, I asked you for information on what companies are actually using
>>> *your*
>>> service. You claim to be involved with a huge % of all transactions. If
>>> that is
>>> in fact true, obviously it shouldn't be hard to provide some examples of
>>> merchants using GAP600 to accept unconfirmed txs.
>>>
>>
>> As already posted here
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021240.html
>> Max CEO from Coinspaid who has provided Cpoinspaid address clusters, see
>> link, is available to discuss further and may choose to share further
>> information on the merchants they support.
>>
>>>
>>> > I don't see it being necessarily an either/or approach here. The risk
>>> > looking to be mitigated with FullRBF seems to be able to be mitigated
>>> with
>>> > FullRBF but with a swop limitation of at least the Inputs of Trx1
>>> being in
>>> > Trx2 - no flagging required. Added to this all these trxs always have
>>> the
>>> > OptinRBF so if these platforms need to be able to recreate completely
>>> their
>>> > trxs they have that option as well. The option to Swop out or bump up
>>> trxs
>>> > seems to be well covered under those two options.
>>>
>>> You are not correct. One of the most important use-cases for full-rbf is
>>> multi-party transactions; adding that limitation to full-rbf negates that
>>> usecase. See my post on why full-rbf makes DoS attacks on multiparty
>>> protocols
>>> significantly more expensive:
>>>
>>>
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021322.html
>>
>>
>> I also note that there is ongoing debate as to the need for full RBF see
>> here
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021331.html
>> .
>>
>> This seems to be an extreme edge case - with Opt-in RBF, FSS Full RBF and
>> common sense - offering enough coverage to mitigate.
>>
>> 0-conf although may not be liked by some actors in Bitcoin, is engaged
>> with free choice and understanding of the risks. 0-conf is a long standing
>> and significant use case which should not be ignored. 0-conf demise should
>> be viewed as being a major and unnecessary cost to FullRBF as currently
>> implemented.
>>
>>> --
>>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>>
>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">&gt; 0-conf on Bitcoin with its understood risks is a sign=
ificant=C2=A0use case<br><div><br>and that use case doesn&#39;t change, at =
all, with full rbf.=C2=A0 =C2=A0the risk profile will, likely, remain the s=
ame.=C2=A0 =C2=A0observation of the fee paid, history of doing business wit=
h the customer, transaction size are all needed.</div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jan 16, 2023=
 at 1:50 PM Daniel Lipshitz via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-d=
ev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt;=
 wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div dir=3D"ltr">Some further clarity on our unique trx hashes que=
ried to our platform, our initial and followup numbers on unique trx hashes=
 queried were not accurate - apologies. Bitcoin addresses queried and Usd v=
alue and unique were accurate. This is as a result of our platform viewing =
each queried bitcoin address as a transaction from our point of view.<div><=
br><div>=C2=A0November 2022<br>=C2=A0 Total queried unique bitcoin address-=
 circa 1.5m trxs<br>=C2=A0 Unique Bitcoin trx hashes queried- circa 500k</d=
iv><div>=C2=A0 USD value - circa 220m<br>=C2=A0 December 2022<br>=C2=A0 =C2=
=A0Total queried unique bitcoin address- circa 1.7m trxs=C2=A0=C2=A0</div><=
div><div><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div style=3D"f=
ont-size:12.8px"><span style=3D"font-size:small">=C2=A0 =C2=A0</span><span =
style=3D"font-size:small">Unique Bitcoin trx hashes queried - circa 500k</s=
pan></div><div style=3D"font-size:12.8px"><span style=3D"font-size:small">=
=C2=A0 =C2=A0</span><span style=3D"font-size:small">USD value - circa 200m<=
/span></div><div style=3D"font-size:12.8px"><span style=3D"font-size:small"=
><br></span></div><div>There are further merchants and service providers wh=
o enable 0-conf on Bitcoin who are not working via our platform - I do not =
know their numbers but believe they are=C2=A0significant. 0-conf on Bitcoin=
 with its understood risks is a significant=C2=A0use case.</div><div><br></=
div><div>For third party clarification please see=C2=A0<a href=3D"https://l=
ists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html" t=
arget=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/20=
22-December/021239.html</a>=C2=A0 and=C2=A0<a href=3D"https://lists.linuxfo=
undation.org/pipermail/bitcoin-dev/2022-December/021238.html" target=3D"_bl=
ank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/=
021238.html</a></div><div style=3D"font-size:12.8px">______________________=
__________</div><div style=3D"font-size:12.8px"><br></div><div style=3D"fon=
t-size:12.8px"><font face=3D"tahoma, sans-serif">Daniel Lipshitz</font></di=
v><div style=3D"font-size:12.8px;color:rgb(0,0,0)"><font face=3D"tahoma, sa=
ns-serif">GAP600|=C2=A0<a href=3D"http://www.gap600.com/" target=3D"_blank"=
>www.gap600.com</a></font></div><div style=3D"font-size:12.8px;color:rgb(0,=
0,0)"><br></div></div></div></div></div><br><br></div></div></div><br><div =
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Jan 14,=
 2023 at 10:15 PM Daniel Lipshitz &lt;<a href=3D"mailto:daniel@gap600.com" =
target=3D"_blank">daniel@gap600.com</a>&gt; wrote:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div><=
div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div style=3D"font-size:1=
2.8px"><br></div></div></div></div></div><br></div><br><div class=3D"gmail_=
quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Jan 14, 2023 at 1:53 A=
M Peter Todd &lt;<a href=3D"mailto:pete@petertodd.org" target=3D"_blank">pe=
te@petertodd.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex">On Sun, Dec 18, 2022 at 10:06:15AM +0200, Daniel Lipshitz w=
rote:<br>
&gt; GAP600 is not a trxs processor or liquidity provider we service mercha=
nts,<br>
&gt; payment processors &amp; non-custodial liquidity providers - our servi=
ce is<br>
&gt; purely the 0-conf enabling our clients to accept 0-conf. Clients acces=
s our<br>
&gt; service via API - sending us the Trx hash &amp; output address. Our se=
rvice is<br>
&gt; not based on AML/KYC it is purely an analysis of the Bitcoin network.<=
br>
<br>
I checked and to sign up for your service, you ask for the name, phone numb=
er,<br>
email, and company name.<br>
<br>
That is an example of AML/KYC. By learning the tx hash and output address, =
you<br>
learn which addresses are associated with what real world entity is paying =
for<br>
your service. You learning that information for what you claim is ~10% of a=
ll<br>
transactions is a significant privacy concern. On that basiss alone, I woul=
d<br>
argue that full-rbf should be implemented specifically to destroy your busi=
ness<br>
and stop the collection of that data.<br>
<br></blockquote><div>We have standard commercial information about the pay=
ment processors, non custodial liquidity providers and merchants which beco=
me our clients - we do not have any kyc/aml information or telephone number=
 on who is sending our clients the bitcoin for deposit.=C2=A0 For us=C2=A0t=
hese are just bitcoin Trx which our clients choose to benefit from 0-conf d=
eposit recognition. Our service is provided via API with the only informati=
on our clients share with us, regarding a specific bitcoin transaction, bei=
ng public bitcoin information like trx hash and output address.</div><div><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; I am not at liberty to share names of other services which have develo=
ped<br>
&gt; their own 0-conf service - they include a payment processor on a gambl=
ing<br>
&gt; platform which services multiple gambling operators, a standalone gami=
ng<br>
&gt; payment processor, and a payment processor recently I have come across=
. We<br>
&gt; also do not have a significant presence in Asia - so I don&#39;t have<=
br>
&gt; visibility there.<br>
<br>
No, I asked you for information on what companies are actually using *your*=
<br>
service. You claim to be involved with a huge % of all transactions. If tha=
t is<br>
in fact true, obviously it shouldn&#39;t be hard to provide some examples o=
f<br>
merchants using GAP600 to accept unconfirmed txs.<br></blockquote><div><br>=
</div><div>As already posted here=C2=A0<a href=3D"https://lists.linuxfounda=
tion.org/pipermail/bitcoin-dev/2022-December/021240.html" target=3D"_blank"=
>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/0212=
40.html</a> Max CEO from Coinspaid who has provided Cpoinspaid address clus=
ters, see link, is available to discuss further and may choose to share fur=
ther information on the merchants they support.=C2=A0=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex">
<br>
&gt; I don&#39;t see it being necessarily an either/or approach here. The r=
isk<br>
&gt; looking to be mitigated with FullRBF seems to be able to be mitigated =
with<br>
&gt; FullRBF but with a swop limitation of at least the Inputs of Trx1 bein=
g in<br>
&gt; Trx2 - no flagging required. Added to this all these trxs always have =
the<br>
&gt; OptinRBF so if these platforms need to be able to recreate completely =
their<br>
&gt; trxs they have that option as well. The option to Swop out or bump up =
trxs<br>
&gt; seems to be well covered under those two options.<br>
<br>
You are not correct. One of the most important use-cases for full-rbf is<br=
>
multi-party transactions; adding that limitation to full-rbf negates that<b=
r>
usecase. See my post on why full-rbf makes DoS attacks on multiparty protoc=
ols<br>
significantly more expensive:<br>
<br>
<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-Jan=
uary/021322.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxf=
oundation.org/pipermail/bitcoin-dev/2023-January/021322.html</a></blockquot=
e><div><br></div><div>I also note that there is ongoing debate as to the ne=
ed for full RBF see here=C2=A0<a href=3D"https://lists.linuxfoundation.org/=
pipermail/bitcoin-dev/2023-January/021331.html" target=3D"_blank">https://l=
ists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021331.html</a>=
 .=C2=A0</div><div><br></div><div>This seems to be an extreme edge case - w=
ith Opt-in RBF, FSS Full RBF and common sense - offering enough coverage to=
 mitigate.=C2=A0</div><div><br></div><div>0-conf although may not be liked =
by some actors in Bitcoin, is engaged with free choice and understanding of=
 the risks. 0-conf is a long standing and significant use case which should=
 not be ignored. 0-conf demise should be viewed as being a major and unnece=
ssary cost to FullRBF as currently implemented.<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org"=
 rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</blockquote></div></div>
</blockquote></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000047eeb805f278bebc--