MIME-Version: 1.0
References: <CACkWPs8-rZpGSJSEyLsg9gVAuPpHztXWSZvfGscGJCn05th0DQ@mail.gmail.com>
 <CALZpt+GnTE+LMSMHVt-E7Uq0FeuqrSKyr1m9OJa_yKkh6MrgzA@mail.gmail.com>
In-Reply-To: <CALZpt+GnTE+LMSMHVt-E7Uq0FeuqrSKyr1m9OJa_yKkh6MrgzA@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Fri, 2 Dec 2022 17:35:39 -0500
Message-ID: <CALZpt+HFFwY4XECNZj3XLqnaumPeDjrwvnCsRa3vsGQfuXn8wA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000afd5b705eedff5d1"
Subject: [bitcoin-dev] Fwd: [Opt-in full-RBF] Zero-conf apps in immediate
	danger
Precedence: list

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

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, nor 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.html
[3]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
[4]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021135.html
[5]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021144.html

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

<div dir=3D"ltr">Hi Daniel,<br><div class=3D"gmail_quote"><div dir=3D"ltr">=
<br>From my understanding of GAP600, you&#39;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-n=
ode operators and a subset of the mining hashrate would lower the cost of d=
ouble-spend attack by lamda users, therefore increasing the risk exposure o=
f your users. This increased risk exposure could lead you to alter the acce=
ptance of incoming zero-conf transactions, AFAICT in a similar reasoning as=
 exposed by Bitrefill earlier this year [0].<br><br>About the statistics yo=
u&#39;re asking for considerations, few further questions, on those 1.5M tr=
ansactions per month, a) how many are Bitcoin-only (as I understand to be m=
ulti-cryptocurrencies), b) how many are excluded from zeroconf due to facto=
rs like RBF, long-chain of unconfirmed ancestors or too high-value and c) w=
hat has been the average feerate (assuming a standard size of 200 bytes) ?<=
br><br>My personal position on fullrbf is still the same as expressed in #2=
6525 [1]. As a community, I think we still don&#39;t have conceptual consen=
sus on deploying full-rbf, nor to remove it. In the direction of removing t=
he current option from Bitcoin Core, I think the prerequisite to address ar=
e 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 al=
l its stakeholders) should restrain user choice in policy settings in the n=
ame of preserving mining income and established use-case stability.<br><br>=
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 c=
orresponding mining income. Since then, alternative paths to solve this DoS=
 vector have been devised, all with their own trade-offs and conceptual iss=
ues [4] [5].<br><br>Best,<br>Antoine<br><br>[0] <a href=3D"https://lists.li=
nuxfoundation.org/pipermail/bitcoin-dev/2022-October/021070.html" target=3D=
"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Octob=
er/021070.html</a><br>[1] <a href=3D"https://github.com/bitcoin/bitcoin/pul=
l/26525#issuecomment-1319499006" target=3D"_blank">https://github.com/bitco=
in/bitcoin/pull/26525#issuecomment-1319499006</a><br>[2] <a href=3D"https:/=
/lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html" tar=
get=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022=
-June/020557.html</a><br>[3] <a href=3D"https://lists.linuxfoundation.org/p=
ipermail/lightning-dev/2021-May/003033.html" target=3D"_blank">https://list=
s.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html</a><br>[=
4] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-=
October/021135.html" target=3D"_blank">https://lists.linuxfoundation.org/pi=
permail/bitcoin-dev/2022-October/021135.html</a><br>[5] <a href=3D"https://=
lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021144.html" =
target=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2=
022-November/021144.html</a><br></div>
</div></div>

--000000000000afd5b705eedff5d1--