path: root/fd/a7fb4c115ada51fb58966d47f4de1f28b7fbd2

Return-Path: <antoine.riard@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 35DD0C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  2 Dec 2022 01:53:01 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id F17676112A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  2 Dec 2022 01:53:00 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org F17676112A
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=JThtohnA
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id G-K93URA7A2s
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  2 Dec 2022 01:52:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 905A4610F4
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com
 [IPv6:2607:f8b0:4864:20::d34])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 905A4610F4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  2 Dec 2022 01:52:59 +0000 (UTC)
Received: by mail-io1-xd34.google.com with SMTP id d18so2280186iof.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 01 Dec 2022 17:52:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=ekaeNLlH9h6BfeqbQDZm15QvE3v0yWtoGyDwIOOMzrc=;
 b=JThtohnAUMPwDCa+CPjAWaPFVUpbbe4qnvMgZRp9lNrJFmRykL1jKHu5KtmLgu7uyn
 sp2mHpfhK3fUjVJBjnWdvluDfppLCycRblcOFiETq0NtEvDAydI+tCeWjvda0c2oYBBX
 6B1CKjilPcvRnq+uEC98SaocKR/dUtyy/bKu906LJjSgN65uu61sSxFvl1x6M0sEEDk2
 x54Xf+AirV7qqZhYy96CRmXPwduRoGOYmSU7mQbF5y1gv8QJzGzpgLbjFEEOImN42+NL
 VGt/8IwXFegzEjCtbKdVDgur2tw03x/qoaCYvv1SwXMp1U3SuQZnrwzIO+f01qO333+6
 UsFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=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=ekaeNLlH9h6BfeqbQDZm15QvE3v0yWtoGyDwIOOMzrc=;
 b=WOsZKIjaqXaFXTJOstBSWK1dQw7p+zqcxuhKoZB9mnoxEjje5jnwpURZxhcME4Nn+T
 2OmRrcwmwCWoV3EjyNJpFwEP/5chiSB9h9TNz3OVpovlszRCM7FwOpcz/VvyewjHf+JK
 IUqCE4eWrwcQ1ClYfcRel2R+zEntCNjBdNAINfgiFULh+szwPb30sr9A1BZ3+ln7cdRU
 voHS+6MyJahdud9l5oJhWN/gc6CcqGvIhoKk+plbu2AmaQyGf90S7ZiMUA5Rcpca0xyu
 IOceM0LOXf7WQp69mPUx1GhoEqgvPuGLuIwqRwP93uuCDuGj2qgO43yMuRdZo5xP+sw4
 Rkxw==
X-Gm-Message-State: ANoB5pnT5lzA25CillWxvbZ/bbs1DRsc5SlVAjW6M2XJMQtqlWQxsKi8
 JRx17DvUpAtqm7JwiGxnPv/z/E/hY2RaYYml6gXUQp1nZdc=
X-Google-Smtp-Source: AA0mqf7f3CCbxUPlUFnoBGFVwpr8XVFcozLs02pkri4P1zUc02Ozuog4etERAwCgiuY07Rsu+cGgG8AY6NDX0MrMfdA=
X-Received: by 2002:a05:6638:3463:b0:38a:141c:414a with SMTP id
 q35-20020a056638346300b0038a141c414amr2226951jav.179.1669945978492; Thu, 01
 Dec 2022 17:52:58 -0800 (PST)
MIME-Version: 1.0
References: <CACkWPs8-rZpGSJSEyLsg9gVAuPpHztXWSZvfGscGJCn05th0DQ@mail.gmail.com>
In-Reply-To: <CACkWPs8-rZpGSJSEyLsg9gVAuPpHztXWSZvfGscGJCn05th0DQ@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Thu, 1 Dec 2022 20:52:46 -0500
Message-ID: <CALZpt+GnTE+LMSMHVt-E7Uq0FeuqrSKyr1m9OJa_yKkh6MrgzA@mail.gmail.com>
To: Daniel Lipshitz <daniel@gap600.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000d79cb505eece98b5"
X-Mailman-Approved-At: Sat, 03 Dec 2022 00:19:46 +0000
Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate
	danger
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, 02 Dec 2022 01:53:01 -0000

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

Hi Daniel,

From my understanding of GAP600, you're operating a zero-conf risk analysis
business, which is integrated and leveraged by payment processors/liquidity
providers and merchants. A deployment of fullrbf by enough full-node
operators and a subset of the mining hashrate would lower the cost of
double-spend attack by lamda users, therefore increasing the risk exposure
of your users. This increased risk exposure could lead you to alter the
acceptance of incoming zero-conf transactions, AFAICT in a similar
reasoning as exposed by Bitrefill earlier this year [0].

About the statistics you're asking for considerations, few further
questions, on those 1.5M transactions per month, a) how many are
Bitcoin-only (as I understand to be multi-cryptocurrencies), b) how many
are excluded from zeroconf due to factors like RBF, long-chain of
unconfirmed ancestors or too high-value and c) what has been the average
feerate (assuming a standard size of 200 bytes) ?

My personal position on fullrbf is still the same as expressed in #26525
[1]. As a community, I think we still don't have conceptual consensus on
deploying full-rbf, neither to remove it. In the direction of removing the
current option from Bitcoin Core, I think the prerequisite to address are
the qualification of enough economic flows at risk and the presence of a
sizable loss in miners income. Beyond that, I think there is still the open
question if we (we, as the Bitcoin protocol development community, with all
its stakeholders) should restrain user choice in policy settings in the
name of preserving mining income and established use-case stability.

To recall, the original technical motivation of this option, and the wider
smoother deployment was to address a DoS vector affecting another class of
use-case: multi-party transactions like coinjoin and contracting protocols
like Lightning [2] [3]. All of them expect to generate economic flows and
corresponding mining income. Since then, alternative paths to solve this
DoS vector have been devised, all with their own trade-offs and conceptual
issues [4] [5].

Best,
Antoine

[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021070=
.html
[1] https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1319499006
[2]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.ht=
ml
[3]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.h=
tml
[4]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021135=
.html
[5]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/02114=
4.html

Le jeu. 1 d=C3=A9c. 2022 =C3=A0 07:32, Daniel Lipshitz via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :

> HI All
>
> I am the CEO of GAP600. We guarantee zero confirmed Bitcoin and other
> crypto  transactions, BTC is a primary part of our business. Our guarante=
e
> enables our customers to recognise zero-conf deposits. We reimburse our
> clients value of the trx should we get it wrong and a transaction we
> confirmed gets double spent.
>
> Should full RBF become default enabled and significantly adopted this
> would have a major impact on the capacity to accept zerof confs on mainne=
t.
> With the end result being this use case will be forced to move to a
> different chain, with lightning being just another option.
>
> I wanted to share some statistics about how significant this use case is.
> GAP600 clients are primarily payment processors and non custodial
> liquidity providers; you can see some of our clients on our site
> www.gap600.com. There are also merchants who have developed their own
> tools so GAP600 statistics are only a subset of the full use case.
>
> I do not know of any wallet, exchange or custodian who accepts zero conf
> without having some sort of solution in place. The market seems to be ful=
ly
> aware of the risks of zero-conf. The opt-RBF seems to be a solution which
> gives a clear free choice for actors.
>
> Statistics for consideration as a sample of the zero conf use case -
>
>
>    1. As of end of Nov 2022 - GAP600 has processed i.e responded to circa
>    15M transactions
>    2. These transactions have a cumulative value of 2.3B USD value.
>    3. We currently are seeing circa 1.5M transactions queired per month.
>
>
> It's a sizable amount of trxs on mainet and we are by no means the full
> market of platforms accepting zero-conf.  I realise there are other
> considerations which BTC has,  I would urge you to take into account the
> major risk being placed on this significant market share when deciding to
> make this feature default enabled and encouraging full adoption.
>
> Thank you for your consideration
> Daniel
> ________________________________
>
> Daniel Lipshitz
> GAP600| www.gap600.com
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Hi Daniel,<br><br>From my understanding of GAP600, you&#39=
;re operating a zero-conf risk analysis business, which is integrated and l=
everaged by payment processors/liquidity providers and merchants. A deploym=
ent of fullrbf by enough full-node operators and a subset of the mining has=
hrate would lower the cost of double-spend attack by lamda users, therefore=
 increasing the risk exposure of your users. This increased risk exposure c=
ould lead you to alter the acceptance of incoming zero-conf transactions, A=
FAICT in a similar reasoning as exposed by Bitrefill earlier this year [0].=
<br><br>About the statistics you&#39;re asking for considerations, few furt=
her questions, on those 1.5M transactions per month, a) how many are Bitcoi=
n-only (as I understand to be multi-cryptocurrencies), b) how many are excl=
uded from zeroconf due to factors like RBF, long-chain of unconfirmed ances=
tors or too high-value and c) what has been the average feerate (assuming a=
 standard size of 200 bytes) ?<br><br>My personal position on fullrbf is st=
ill the same as expressed in #26525 [1]. As a community, I think we still d=
on&#39;t have conceptual consensus on deploying full-rbf, neither to remove=
 it. In the direction of removing the current option from Bitcoin Core, I t=
hink the prerequisite to address are the qualification of enough economic f=
lows at risk and the presence of a sizable loss in miners income. Beyond th=
at, I think there is still the open question if we (we, as the Bitcoin prot=
ocol development community, with all its stakeholders) should restrain user=
 choice in policy settings in the name of preserving mining income and esta=
blished use-case stability.<br><br>To recall, the original technical motiva=
tion of this option, and the wider smoother deployment was to address a DoS=
 vector affecting another class of use-case: multi-party transactions like =
coinjoin and contracting protocols like Lightning [2] [3]. All of them expe=
ct to generate economic flows and corresponding mining income. Since then, =
alternative paths to solve this DoS vector have been devised, all with thei=
r own trade-offs and conceptual issues [4] [5].<br><br>Best,<br>Antoine<br>=
<br>[0] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/=
2022-October/021070.html">https://lists.linuxfoundation.org/pipermail/bitco=
in-dev/2022-October/021070.html</a><br>[1] <a href=3D"https://github.com/bi=
tcoin/bitcoin/pull/26525#issuecomment-1319499006">https://github.com/bitcoi=
n/bitcoin/pull/26525#issuecomment-1319499006</a><br>[2] <a href=3D"https://=
lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html">http=
s://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html</=
a><br>[3] <a href=3D"https://lists.linuxfoundation.org/pipermail/lightning-=
dev/2021-May/003033.html">https://lists.linuxfoundation.org/pipermail/light=
ning-dev/2021-May/003033.html</a><br>[4] <a href=3D"https://lists.linuxfoun=
dation.org/pipermail/bitcoin-dev/2022-October/021135.html">https://lists.li=
nuxfoundation.org/pipermail/bitcoin-dev/2022-October/021135.html</a><br>[5]=
 <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-No=
vember/021144.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev=
/2022-November/021144.html</a><br></div><br><div class=3D"gmail_quote"><div=
 dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0jeu. 1 d=C3=A9c. 2022 =C3=A0=C2=
=A007:32, Daniel Lipshitz via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; a=
 =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr">HI All<div><br></div><div>I am the CEO of GAP600. We gu=
arantee zero confirmed Bitcoin and other crypto=C2=A0 transactions, BTC is =
a primary part of our business. Our guarantee enables our customers to reco=
gnise zero-conf deposits. We reimburse our clients value of the trx should =
we get it wrong and a transaction we confirmed gets double spent.</div><div=
><br></div><div>Should full RBF become default enabled and significantly ad=
opted this would have a major impact on the capacity to accept zerof confs =
on mainnet. With the end result being this use case will be forced to move =
to a different chain, with lightning being just another=C2=A0option.</div><=
div><br></div><div>I wanted to share some statistics about how significant =
this use case is.=C2=A0</div><div>GAP600 clients are primarily payment proc=
essors and non custodial liquidity=C2=A0providers; you can see some of our =
clients on our site <a href=3D"http://www.gap600.com" target=3D"_blank">www=
.gap600.com</a>. There are also merchants who have developed their own tool=
s so GAP600 statistics are only a subset of the full use case.=C2=A0</div><=
div><br></div><div>I do not know of any wallet, exchange or custodian who a=
ccepts zero conf without having some sort of solution=C2=A0in place. The ma=
rket seems to be fully aware of the risks of zero-conf. The opt-RBF seems t=
o be a solution which gives a clear free choice for actors.</div><div><br><=
/div><div>Statistics for consideration as a sample of the zero conf use cas=
e -=C2=A0</div><div><br></div><div><ol><li>As of end of Nov 2022 - GAP600 h=
as processed i.e responded to circa 15M transactions</li><li>These transact=
ions have a cumulative value of 2.3B USD value.=C2=A0</li><li>We currently =
are seeing circa 1.5M transactions queired per month.=C2=A0</li></ol></div>=
<div><br></div><div>It&#39;s a sizable amount of trxs on mainet and we are =
by no means the full market of platforms accepting zero-conf.=C2=A0=C2=A0I =
realise there are other considerations which BTC has,=C2=A0 I would urge yo=
u to take into account the major risk being placed on this significant mark=
et share when deciding to make this feature default enabled and encouraging=
=C2=A0full adoption.</div><div><br></div><div>Thank you for your considerat=
ion</div><div>Daniel</div><div><div dir=3D"ltr"><div dir=3D"ltr"><div dir=
=3D"ltr"><div style=3D"font-size:12.8px">________________________________</=
div><div style=3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8p=
x"><font face=3D"tahoma, sans-serif">Daniel Lipshitz</font></div><div style=
=3D"font-size:12.8px;color:rgb(0,0,0)"><font face=3D"tahoma, sans-serif">GA=
P600|=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></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000d79cb505eece98b5--