Feedback-ID: i525146e8:Fastmail
Date: Fri, 13 Jan 2023 18:53:45 -0500
From: Peter Todd <pete@petertodd.org>
To: Daniel Lipshitz <daniel@gap600.com>
Message-ID: <Y8HvCbBd5+pm8Uj2@petertodd.org>
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="S+HNksSHv2SNbjlu"
Content-Disposition: inline
In-Reply-To: <CACkWPs_6z7UyXzejTqjy=i+SkSz-76VdzZ20K1DzcVJxan_HZg@mail.gmail.com>
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


--S+HNksSHv2SNbjlu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 o=
ur
> 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 numb=
er,
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 a=
ll
transactions is a significant privacy concern. On that basiss alone, I would
argue that full-rbf should be implemented specifically to destroy your busi=
ness
and stop the collection of that data.

> 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 tha=
t is
in fact true, obviously it shouldn't be hard to provide some examples of
merchants using GAP600 to accept unconfirmed txs.

> 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 the=
ir
> 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 protoc=
ols
significantly more expensive:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021322=
=2Ehtml

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

--S+HNksSHv2SNbjlu
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmPB7wcACgkQLly11TVR
LzdOCw/9FWYPVifH9btGD+Ju35O2KukI1hfsYaUE2sq425sFmSLMPnoY3OHN7PPp
9AhnRQ58govIKwr/Yb2ye86O4/Nb7IBvBPSCDWrsDT7EQ0a+YeAbY95vJo8W28DJ
wxz1gUynrG9S/4EtyF+bSl5a9BUdw3TqDSWy0MMCs9E5eeja/Y38YCBB1Cc+rUMg
7hgCJJdJbPU9mgZdFZ8TSr83t6T3TMk2EFb+/1YdMxLHRF/HO1E2Y4k5dnjS24VH
Ba+U+3xwzfyQku1Oduq1inHtaD23TdyAjby8M54jmwWAilp7jNCwHHFXibe3qhoP
OY2gmSKvb6kCKGj34OIxbaSifNTHeZI515tKeyzMVwkAlVQCI8LU3ri/4a7jM/7n
T+P/CkMtsOJlSsjMybE3GhB0DDgsNme8JIuSJbyXpE/mNExEpkABjlmne4WxE4zQ
Jzfa4hCzDNoK4zMQ25GplDkLECYZfSuGYERoep7d4dXh8kJrVLQoIRw+6zgwC660
dEnwzp/TIBfoj0OKS5iM0I38qxjz0wkgiPbv6j1s4euBFDIzUMPqMBamKWMVlMZD
aY12IJSEWI8CFi3Mg0h4475+id3CN2O416YUzvO0Dnk2qFGTMVbs1SrM0IVjzvt5
qBz+P1gA5L1FwQ6BF3Ag/eHcw6kkc/wGzmuTJovfFo4jYPjiMAc=
=5UFU
-----END PGP SIGNATURE-----

--S+HNksSHv2SNbjlu--