Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8A75BC0032 for ; 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 ; 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 ; 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 ; Mon, 16 Jan 2023 10:19:48 +0000 (UTC) Received: by mail-vs1-xe2f.google.com with SMTP id t10so17963038vsr.3 for ; 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: In-Reply-To: From: Daniel Lipshitz Date: Mon, 16 Jan 2023 12:19:35 +0200 Message-ID: To: Peter Todd Content-Type: multipart/alternative; boundary="00000000000033385305f25eec5e" X-Mailman-Approved-At: Mon, 16 Jan 2023 18:50:23 +0000 Cc: bitcoin-dev , John Carvalho 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: > > > > On Sat, Jan 14, 2023 at 1:53 AM Peter Todd 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
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.

=C2=A0November 2022
=C2=A0 Total queried unique bitcoin = address- circa 1.5m trxs
=C2=A0 Unique Bitcoin trx hashes queried- circa= 500k
=C2=A0 USD value - circa 220m
=C2=A0 December 2022
= =C2=A0 =C2=A0Total queried unique bitcoin address- circa 1.7m trxs=C2=A0=C2= =A0
=C2=A0 =C2=A0Unique Bitcoi= n trx hashes queried - circa 500k
=C2=A0 =C2=A0USD value - circa 200m

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.

______________________= __________

Daniel Lipshitz
GAP600|=C2=A0www.gap600.com




On Sat, Jan 14,= 2023 at 10:15 PM Daniel Lipshitz <= daniel@gap600.com> wrote:

<= /div>


On Sat, Jan 14, 2023 at 1:53 AM Peter Todd <<= a href=3D"mailto:pete@petertodd.org" target=3D"_blank">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 mercha= nts,
> payment processors & non-custodial liquidity providers - our servi= ce is
> purely the 0-conf enabling our clients to accept 0-conf. Clients acces= s our
> service via API - sending us the Trx hash & output address. Our se= rvice is
> not based on AML/KYC it is purely an analysis of the Bitcoin network.<= br>
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 woul= d
argue that full-rbf should be implemented specifically to destroy your busi= ness
and stop the collection of that data.

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.
<= br>
> I am not at liberty to share names of other services which have develo= ped
> their own 0-conf service - they include a payment processor on a gambl= ing
> platform which services multiple gambling operators, a standalone gami= ng
> 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<= br> > 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 o= f
merchants using GAP600 to accept unconfirmed txs.

=
As already posted here=C2=A0https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/0212= 40.html 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

> I don't see it being necessarily an either/or approach here. The r= isk
> 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 bein= g 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 protoc= ols
significantly more expensive:

https://lists.linuxf= oundation.org/pipermail/bitcoin-dev/2023-January/021322.html

I also note that there is ongoing debate as to the ne= ed for full RBF see here=C2=A0https://l= ists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021331.html= .=C2=A0

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

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.
--
http= s://petertodd.org 'peter'[:-1]@petertodd.org
--00000000000033385305f25eec5e--