path: root/fb/ae117b3349d2a732495520c46d4eeaef57ea85

Return-Path: <daniel@gap600.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D5D7AC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 17 Jan 2023 17:27:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 9AD3F416D2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 17 Jan 2023 17:27:35 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 9AD3F416D2
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gap600.com header.i=@gap600.com
 header.a=rsa-sha256 header.s=google header.b=vuUonS/H
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level: 
X-Spam-Status: No, score=-2.089 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,
 T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id HYDP_SiN5lAi
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 17 Jan 2023 17:27:33 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 41EAA416C2
Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com
 [IPv6:2607:f8b0:4864:20::a36])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 41EAA416C2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 17 Jan 2023 17:27:33 +0000 (UTC)
Received: by mail-vk1-xa36.google.com with SMTP id e132so4812460vke.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 17 Jan 2023 09:27:33 -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=R2jn67TUcPZRZqJIGH0koxAs5KVsiLkNyGrwIIXjK4g=;
 b=vuUonS/HmXHAeduE4/dvCPGcmY1EINSBXaCX9eHphlWrr1F5BUOqr1HRyxFVWEaRil
 WpoelCJf89e/8wbirDkC2L5kkggEW/E5mluiJEuWDz6Zii6Nc7+PIGJZMed3a1yaZ2rJ
 Kp+DJBeOSpwTarEbts5bRkM5TGmLzq37Vv0wohNHA2N+eTYJT9zENV2WqoJ1Z4yFGlLQ
 sRv6I+II/OEv7YmahhbJMKkTci0Naf/ujTnBdyQrjuFn5ni4K/sbLuGPWe2FnUZ7tTMn
 nBiauzEfuQlKmXKTdt8ZGSxxNhaaon54GmLOsKq/40+eYhnZAhvwhDvgTWLIV3ni/c06
 Oo4g==
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=R2jn67TUcPZRZqJIGH0koxAs5KVsiLkNyGrwIIXjK4g=;
 b=o7mfsUaF4/dn6qdJZc8Hh+OwxUrKiWkTqeqTnr71Wl3BGibh+FzOQgoZKBbbVeuPYR
 7dlBnENfU2zBcrv4BIDk6wlRI15nBxaZ2qSDH8StjX4Ol3p28Pq4RtC5NgdLFdST9XFo
 p9PyJpovmG964K15yBF5SyeiZjrCj23yG+9O5akG5WjYQSavgSmeTcs2rz2q4K4whfVs
 rQ96pkVtxIehefXcTHGNsM9x5ifJErCxiOkai87WDBuogyiXCPlJh9YfFHoeHLDvNp/k
 29XEX0JtY5b+9h/mRFzCF/5eHWi417cdGfcLg/ihjN1h/V1W+Fkzcxl6wvgQZbiwrl73
 9hBg==
X-Gm-Message-State: AFqh2kq4etu0GHaBdihsCso7oXCJSmaBHD7CiBOZf/giKb+4Ixm87iXI
 grdsSP287HkUyvEeEWMF4+FRCjOOj/7noNNMpVTZuQ==
X-Google-Smtp-Source: AMrXdXt6UN6y7q2AlPbXTPPW59+FFePA10bMtCm+ks2A9Ql/zpeVdjaxROqd51zomK3hZ3jopoElQAjfdQA2FIaok4A=
X-Received: by 2002:a1f:2bd1:0:b0:3d5:399b:e9 with SMTP id
 r200-20020a1f2bd1000000b003d5399b00e9mr510405vkr.24.1673976451683; 
 Tue, 17 Jan 2023 09:27:31 -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>
 <CAJowKgK9VQ3bgZZnnmTBkhF8DFrv08ywEQEC5oTvXX66d=mkoQ@mail.gmail.com>
In-Reply-To: <CAJowKgK9VQ3bgZZnnmTBkhF8DFrv08ywEQEC5oTvXX66d=mkoQ@mail.gmail.com>
From: Daniel Lipshitz <daniel@gap600.com>
Date: Tue, 17 Jan 2023 19:27:13 +0200
Message-ID: <CACkWPs867CH+haR8ZEjnX7kzsruX=TbrhnRX+-XFJpnv=EBHnw@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>
Content-Type: multipart/alternative; boundary="000000000000c3ee7505f2790370"
X-Mailman-Approved-At: Tue, 17 Jan 2023 17:40:39 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 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:27:36 -0000

--000000000000c3ee7505f2790370
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.
>

Currently 0-conf recognition is done without any KYC on the payor, this
includes activities like, gaming, non-custodial trading and applications.
In general OptinRBF is not possible to offer 0-conf since as soon as it is
recognised it can be double spent. Full RBF would make all trxs just like
OptinRBF. FullRBF but with FSS implemented will still enable 0-conf
acceptance.

>
> 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
>>
>

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

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><div class=3D"gmail_quote"><blo=
ckquote 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">&gt; 0-conf =
on Bitcoin with its understood risks is a significant=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 same.=C2=A0 =C2=A0observation =
of the fee paid, history of doing business with the customer, transaction s=
ize are all needed.</div></div></blockquote><div>=C2=A0</div><div>Currently=
 0-conf recognition is done without any KYC on the payor, this includes act=
ivities like, gaming, non-custodial trading and applications. In general Op=
tinRBF is not possible to offer 0-conf since as soon as it is recognised it=
 can be double spent. Full RBF would make all trxs just like OptinRBF. Full=
RBF but with FSS implemented=C2=A0will still enable 0-conf acceptance.</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"><br><div class=3D"gmail_=
quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jan 16, 2023 at 1:50 P=
M Daniel Lipshitz via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.l=
inuxfoundation.org" target=3D"_blank">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 ha=
shes queried to our platform, our initial and followup numbers on unique tr=
x hashes queried were not accurate - apologies. Bitcoin addresses queried a=
nd 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 vie=
w.<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</div><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"font-size:12.8px"><span style=3D"font-size:small">=C2=A0 =C2=A0</s=
pan><span style=3D"font-size:small">Unique Bitcoin trx hashes queried - cir=
ca 500k</span></div><div style=3D"font-size:12.8px"><span style=3D"font-siz=
e:small">=C2=A0 =C2=A0</span><span style=3D"font-size:small">USD value - ci=
rca 200m</span></div><div style=3D"font-size:12.8px"><span style=3D"font-si=
ze:small"><br></span></div><div>There are further merchants and service pro=
viders who 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 o=
n Bitcoin with its understood risks is a significant=C2=A0use case.</div><d=
iv><br></div><div>For third party clarification please see=C2=A0<a href=3D"=
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/02123=
9.html" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitco=
in-dev/2022-December/021239.html</a>=C2=A0 and=C2=A0<a href=3D"https://list=
s.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021238.html" targ=
et=3D"_blank">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 sty=
le=3D"font-size:12.8px"><font face=3D"tahoma, sans-serif">Daniel Lipshitz</=
font></div><div style=3D"font-size:12.8px;color:rgb(0,0,0)"><font face=3D"t=
ahoma, sans-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;c=
olor:rgb(0,0,0)"><br></div></div></div></div></div><br><br></div></div></di=
v><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On S=
at, Jan 14, 2023 at 10:15 PM Daniel Lipshitz &lt;<a href=3D"mailto:daniel@g=
ap600.com" target=3D"_blank">daniel@gap600.com</a>&gt; wrote:<br></div><blo=
ckquote 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"><div><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div style=3D"=
font-size:12.8px"><br></div></div></div></div></div><br></div><br><div clas=
s=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Jan 14, 202=
3 at 1:53 AM Peter Todd &lt;<a href=3D"mailto:pete@petertodd.org" target=3D=
"_blank">pete@petertodd.org</a>&gt; wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex">On Sun, Dec 18, 2022 at 10:06:15AM +0200, Daniel=
 Lipshitz wrote:<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>
</blockquote></div></div>

--000000000000c3ee7505f2790370--