path: root/3a/9f64277b566aa5fc05d9edac32921ce62cafe8

Return-Path: <pete@petertodd.org>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 20A8EC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 13 Jan 2023 23:53:53 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id EC0E341685
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 13 Jan 2023 23:53:52 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org EC0E341685
Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key,
 unprotected) header.d=messagingengine.com header.i=@messagingengine.com
 header.a=rsa-sha256 header.s=fm3 header.b=P3+KxUOu
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.592
X-Spam-Level: 
X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 4YWGuYDyPaMZ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 13 Jan 2023 23:53:51 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 8C0884161B
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com
 [64.147.123.19])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 8C0884161B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 13 Jan 2023 23:53:51 +0000 (UTC)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
 by mailout.west.internal (Postfix) with ESMTP id 7CFC63200922;
 Fri, 13 Jan 2023 18:53:50 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163])
 by compute1.internal (MEProxy); Fri, 13 Jan 2023 18:53:50 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-type:date:date:feedback-id
 :feedback-id:from:from:in-reply-to:in-reply-to:message-id
 :mime-version:references:reply-to:sender:subject:subject:to:to
 :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
 fm3; t=1673654030; x=1673740430; bh=iT4D9fj2s+gnj5PSUo5HvPYSCx4D
 T0W2J///fobgmAM=; b=P3+KxUOukNEL/lZmv3WRUG+2jhALW8kvI919JP1Vxj4a
 ZH3Z7SB37CyGXJRlu6dZS2xFhdeThv52h/kdXiN/xHVq2vGf7ECxEm2m9JF1iuFU
 lX/85HlUdFaEJGh1TFLt1ESFFVRbE8aESMgnmj5a/uqQzW3kOm+USTvRQ1Ff+Mju
 whdhE3+zFEhHOxJTErzRw921U/djbsRSzJeHpzPEgHJp8PgdV085YSKxW5dnN/zY
 kLq6BlVjPjEjPYXHwseMI2buLD+Ki2KnyoIjPT0qcNoBCe8oEL89yvJLgykBAIy8
 q0RWng3zKIilhfMwUVGrzRAWS7S+M4zxyPft0Zd3nw==
X-ME-Sender: <xms:De_BYyyJOwJs5OtprAnw2l0nxmI_tRcQIIi_5AUEHMwEQpY6SPxsdw>
 <xme:De_BY-QLHVU5FcQvUmOc_0LOb44xyoyZW_2ukXZKDzsMHK9SmIWqZDbc8aSz02Nqv
 hHRqjemV2FohbX3uQY>
X-ME-Received: <xmr:De_BY0VAnftvWE7AlyraQKqZBXgyEEED1-RPIEFQXAp0J_XItX4fCDmRrZvOcA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrleelgdduiecutefuodetggdotefrodftvf
 curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
 uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
 fjughrpeffhffvvefukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpefrvghtvghr
 ucfvohguugcuoehpvghtvgesphgvthgvrhhtohguugdrohhrgheqnecuggftrfgrthhtvg
 hrnheptdfhfefgieffteetuddtgeekjefhvddttedtkeffudeileejleektdfglefgieev
 necuffhomhgrihhnpehlihhnuhigfhhouhhnuggrthhiohhnrdhorhhgpdhpvghtvghrth
 houggurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf
 rhhomhepphgvthgvsehpvghtvghrthhouggurdhorhhg
X-ME-Proxy: <xmx:De_BY4jHMcQ8key7vp_MM_UmCC9Le4-iR-tLMRXaYaBtBnDoVQsp-w>
 <xmx:De_BY0DpGWCUQL6abfzIRiwm8HltfCJSdIaG-nETqLuU6If_5GNRZg>
 <xmx:De_BY5JsfjoWxfzIHb-qKsIxPFc_Q8g91eahhYk4nQEdGp_etIqMEQ>
 <xmx:Du_BY3_Ma-wWQSKaygl6jrhu_TEsgj-C1o7ruftvy7qvZ1uGFx1jIA>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 13 Jan 2023 18:53:49 -0500 (EST)
Received: by localhost (Postfix, from userid 1000)
 id D08E85F82C; Fri, 13 Jan 2023 18:53:45 -0500 (EST)
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
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: Fri, 13 Jan 2023 23:53:53 -0000


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