MIME-Version: 1.0
References: <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>
 <Y96HgwjLkF6Bd2DV@petertodd.org>
In-Reply-To: <Y96HgwjLkF6Bd2DV@petertodd.org>
From: Daniel Lipshitz <daniel@gap600.com>
Date: Mon, 6 Feb 2023 14:08:40 +0200
Message-ID: <CACkWPs-78Ytv3dVRD_VsXUFpuqWgwapYuDP8Vy5sR4F12e9fdw@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="000000000000f107c605f406e47a"
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
Precedence: list

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

On Sat, Feb 4, 2023 at 6:28 PM Peter Todd <pete@petertodd.org> wrote:

> On Sat, Jan 14, 2023 at 10:15:30PM +0200, Daniel Lipshitz wrote:
> > 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.
>
> You know who your clients are, and thus every request for information on a
> transaction is reasonably likely to be a deposit associated with the
> client who
> requested it. Learning what addresses are associated with what entity is a
> significant benefit to Chainalysis operations, and there's every reason to
> expect that the data you learn will either be sold or leaked to Chainalysis
> companies.
>

I would estimate based on general discussions with clients and open
research more than 90% of our clients use different AML trx analysis
service providers for trx deposited on their platforms -
completely irrelevant to us or 0-conf. So if these clients were to stop
recognising 0-conf this would have no impact on these AML service providers
access to the data. We service payment processors and liquidity providers
and have little or no insight into which wallets or merchants our clients
service.

 Further to this many of the cluster addresses of our clients and just like
other service providers in the bitcoin space are publicly known - just as
Max had no issue sharing the cluster of his deposit address in his email
which I posted to the list.

>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

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

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Sat, Feb 4, 2023 at 6:28 PM Peter =
Todd &lt;<a href=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>&gt; w=
rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Ja=
n 14, 2023 at 10:15:30PM +0200, Daniel Lipshitz wrote:<br>
&gt; We have standard commercial information about the payment processors, =
non<br>
&gt; custodial liquidity providers and merchants which become our clients -=
 we<br>
&gt; do not have any kyc/aml information or telephone number on who is send=
ing<br>
&gt; our clients the bitcoin for deposit.=C2=A0 For us these are just bitco=
in Trx<br>
&gt; which our clients choose to benefit from 0-conf deposit recognition. O=
ur<br>
&gt; service is provided via API with the only information our clients shar=
e<br>
&gt; with us, regarding a specific bitcoin transaction, being public bitcoi=
n<br>
&gt; information like trx hash and output address.<br>
<br>
You know who your clients are, and thus every request for information on a<=
br>
transaction is reasonably likely to be a deposit associated with the client=
 who<br>
requested it. Learning what addresses are associated with what entity is a<=
br>
significant benefit to Chainalysis operations, and there&#39;s every reason=
 to<br>
expect that the data you learn will either be sold or leaked to Chainalysis=
<br>
companies.<br></blockquote><div><br></div><div>I would estimate based on ge=
neral discussions with clients and open research more than 90% of our clien=
ts use different AML trx analysis service providers for trx deposited on th=
eir platforms - completely=C2=A0irrelevant to us or 0-conf. So if these cli=
ents were to stop recognising 0-conf this would have no impact on these AML=
 service providers access to the data. We service payment processors and li=
quidity providers and have little or no insight into which wallets or merch=
ants our clients service.</div><div><br></div><div>=C2=A0Further to this ma=
ny of the cluster addresses of our clients and just=C2=A0like other service=
 providers in the bitcoin space are publicly=C2=A0known - just as Max had n=
o issue sharing the cluster of his deposit address in his email which I pos=
ted to the list.</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>
-- <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>

--000000000000f107c605f406e47a--