path: root/63/a1e2668b91410c8d0fb0cbc48795241975868e

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 8A75BC0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 16 Jan 2023 10:19:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 65E8740116
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 16 Jan 2023 10:19:50 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 65E8740116
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=QoP0RmyF
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 smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id F-AXNY1QNmJ1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 16 Jan 2023 10:19:49 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org EF883400AC
Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com
 [IPv6:2607:f8b0:4864:20::e2f])
 by smtp2.osuosl.org (Postfix) with ESMTPS id EF883400AC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 16 Jan 2023 10:19:48 +0000 (UTC)
Received: by mail-vs1-xe2f.google.com with SMTP id t10so17963038vsr.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 16 Jan 2023 02:19:48 -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=axWCf4L5g5XwP81DlY3k2AStEKCX1UnYOONFhdw7VB8=;
 b=QoP0RmyF8W/s1L1XNjIDorTXvyLP2ahOKlY9pIvg9qSKTX4pNCbCKYXcXR6qCqt386
 kVZg70x12kF26qDUp3F1c8cP66bch+eTlcEPEjVAmpqSQP6a2LPsSpCUoduen6SYPtkA
 +XZiTYZsBx7zRNXOb3bEfOzM0AUUT7XNSG7AwRmocT8IVQB+zKavZyXAKP47yZd3m8VU
 mhPX16gIAmBtbN3RuGRAtSabhko8b7S5+Icmnq8B8KPVv2yPNPVnaNaF11fFo068W2vw
 8UTQ8gaTxABDQ6hmUAIEUCG05wWtyuQwRJ8XM39uBE9AZSkIm2tm2ZQqsBMyjcQkDdZy
 /fhQ==
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=axWCf4L5g5XwP81DlY3k2AStEKCX1UnYOONFhdw7VB8=;
 b=sSjbhQs+Ra69qAe6cJpVI3P6x0LokoyzjwYhif7I4Bo/EnRtX93twewdV0LCkf2KR7
 NECgYdp+Bkig+VbFC5xk/0P1+nUMKjWHZQ7886FIJfK3JeFogcZZV5W7tTA5SihXpC3p
 nGNf2FBt4ui/n5fDh/dujH6RhwfXzgR/kemgrvqVRVks9kVwrbGP9F/Y45j6vroB4Jxw
 nQv9l+hB9YQ0J9C3DDwjOofXh3saySny7w+uMub1Jh337hwxMJOP6bO/YoBijBWeR8rC
 8hTguu8HEnQ7XXogWy79xYxfw8c6SZ7dt+IQB0pfJ3iABworNFOeOQqTOANQV6seBYoB
 IyaQ==
X-Gm-Message-State: AFqh2koPeuR7W8+5yrACQIUPzBdGzJYjereXEWCrlSl4rU5ta4zEfgno
 a2ix6rpVdMgGV98ocCoKjpGkty/WR278FCSR0U69BA==
X-Google-Smtp-Source: AMrXdXuk//94Rk0LU7y2Yslz1OEGQTjp3/R/sPGD90h1k7vATfJ64UaC4UDXYRoAdRn45AMhfPCV2HfWMlQ4JcIElzA=
X-Received: by 2002:a05:6102:3e84:b0:3d0:d8a3:af2c with SMTP id
 m4-20020a0561023e8400b003d0d8a3af2cmr2626690vsv.74.1673864387172; Mon, 16 Jan
 2023 02:19:47 -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>
In-Reply-To: <CACkWPs_Nqm1663c1q8xHX=A0Gpa7m1kV_QX6t0s8uPOEh3WQLA@mail.gmail.com>
From: Daniel Lipshitz <daniel@gap600.com>
Date: Mon, 16 Jan 2023 12:19:35 +0200
Message-ID: <CACkWPs94npkm9b--vfAraoKxXK-2A0fgv-NBcyRHzSCASuO1Bw@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="00000000000033385305f25eec5e"
X-Mailman-Approved-At: Mon, 16 Jan 2023 18:50:23 +0000
Cc: bitcoin-dev <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: Mon, 16 Jan 2023 10:19:50 -0000

--00000000000033385305f25eec5e
Content-Type: text/plain; charset="UTF-8"

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

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

<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" class=3D"gmail_signature"><div dir=3D"l=
tr"><div dir=3D"ltr"><div style=3D"font-size:12.8px"><span style=3D"font-si=
ze:small">=C2=A0 =C2=A0</span><span style=3D"font-size:small">Unique Bitcoi=
n trx hashes queried - circa 500k</span></div><div style=3D"font-size:12.8p=
x"><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.8=
px"><span style=3D"font-size:small"><br></span></div><div>There are further=
 merchants and service providers who enable 0-conf on Bitcoin who are not w=
orking 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 signifi=
cant=C2=A0use case.</div><div><br></div><div>For third party clarification =
please see=C2=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/bitc=
oin-dev/2022-December/021239.html">https://lists.linuxfoundation.org/piperm=
ail/bitcoin-dev/2022-December/021239.html</a>=C2=A0 and=C2=A0<a href=3D"htt=
ps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021238.h=
tml">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">=
daniel@gap600.com</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);p=
adding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div><div dir=3D"ltr"><d=
iv dir=3D"ltr"><div dir=3D"ltr"><div style=3D"font-size:12.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 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"gmail_quote" style=3D"margin:0p=
x 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>

--00000000000033385305f25eec5e--