path: root/45/1b07716ad26389e6e9b6a9f99af70c89abac56

Return-Path: <john@synonym.to>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B3F68C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Dec 2022 17:26:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 8E9824038B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Dec 2022 17:26:28 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 8E9824038B
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=synonym-to.20210112.gappssmtp.com
 header.i=@synonym-to.20210112.gappssmtp.com header.a=rsa-sha256
 header.s=20210112 header.b=WTcUX4jK
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_NONE=0.001] 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 EMWTiMR497wQ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Dec 2022 17:26:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 1433B40193
Received: from mail-il1-x135.google.com (mail-il1-x135.google.com
 [IPv6:2607:f8b0:4864:20::135])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 1433B40193
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Dec 2022 17:26:26 +0000 (UTC)
Received: by mail-il1-x135.google.com with SMTP id o13so5386154ilc.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 05 Dec 2022 09:26:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=synonym-to.20210112.gappssmtp.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=yUhBc3mgnEmgvxytaFMfvS0tvcbK3XFTNFqUniUUp18=;
 b=WTcUX4jKPRjhy7aglazP4iSXj2TOx8w+qHOyP1cvKUBPODWEDB05WMwC/1PLKeCqmT
 M7eJGBKDMRy8FuFuTHhhH8raiVW3jongDwINwvQ0GD7q0JE5vbGlc0ijtRmyInKmlZ2C
 fIaQmmMO0OqDcQO+kPIjTAUdMBE17mX2FHzds9QcBTvZnyfed8PhVKf+x4gJphFPigoJ
 3KL/srLj4NKYqIxqvu4dasFBEBt0B9lNgxVidjUZVI/cYFD/FlLqbUfBwW+CoSetky7I
 KHAt65wJMqbUJJDyy6f8mQki4rAC1/8QefwovlhIYejS1PefRyW3X+C+ixt8lBwBHujd
 HGyg==
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=yUhBc3mgnEmgvxytaFMfvS0tvcbK3XFTNFqUniUUp18=;
 b=WGws1OdJzECIPc1NlYhqlAUAswaqTFbRdE1pll14ATIeUoykQIyppYxlRq7nbBau+K
 odOl2oRzS67URJC1g/+T9PMo2GZUcaCnScU2NnKMSr7NCrCC7rTtHfvT+SxTfwvSyk7z
 UvV4sFp67xLgGC+1/SUeq0HtS5AugS0TW2a8DD53j6GKkbCiEb2kKmToNLTWjy3SW902
 6CDl/S/ld40Ti93JH/dCI/0NdkGxEJ8IGn8Cy0wsjKGS9DHnWZCEum9Ss8R2G7v3sN24
 rNRph8gHrQ/r5jUSmt3UJJALrds0r1Py16dxI9WEpGoAV+o4qJv34bRXC3C7PeDrLAKK
 2dXg==
X-Gm-Message-State: ANoB5pk6NNZNcAB91i/Or/jCqnp4bzVs96R6qK3SiwcajSg9iUugaHs+
 ieNUX1EN4F5RdDwXh5orYKdiQolVQ33EKVmO39b2hgsNNzrjszG0
X-Google-Smtp-Source: AA0mqf7I3Vgf9oBC6uc2JwOt/x3lxZPozLVQjJWfH23h0Xm/7+BbVWdCgafl0/WYHwJO5f0JEA3fD0060QpqAWIm+qs=
X-Received: by 2002:a05:6e02:1c25:b0:303:3ce6:bb22 with SMTP id
 m5-20020a056e021c2500b003033ce6bb22mr7462207ilh.138.1670261185450; Mon, 05
 Dec 2022 09:26:25 -0800 (PST)
MIME-Version: 1.0
References: <mailman.15.1670068802.22993.bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <mailman.15.1670068802.22993.bitcoin-dev@lists.linuxfoundation.org>
From: John Carvalho <john@synonym.to>
Date: Mon, 5 Dec 2022 17:26:14 +0000
Message-ID: <CAHTn92zCFf+9yNgRZuoJ8L54fxJmPoOwcU3a9kSY5PLoYMk9dA@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org, antoine.riard@gmail.com
Content-Type: multipart/alternative; boundary="000000000000a4330a05ef17fcf4"
X-Mailman-Approved-At: Mon, 05 Dec 2022 18:57:59 +0000
Subject: Re: [bitcoin-dev] bitcoin-dev Digest, Vol 91, Issue 5
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: Mon, 05 Dec 2022 17:26:28 -0000

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

Antoine,


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


Are such prerequisites for feature removal published somewhere? I don't see
any reason why removing a controversial change should be harder than adding
one. Generally, it is impossible to definitively attribute any change in
network condition to one thing in such a complex system, and also difficult
to know how much time is required to express negative effects. The whole
argument here is to prevent disruption of the status quo that has lasted
the whole history of Bitcoin, to avoid taking a speculative risk that
full-RBF, at the expense of zero-conf, is maybe better for miners... or
something.

Further, I feel the mempoolfullrbf feature was rushed through while this
controversy was growing, specifically to attempt to achieve this imaginary
protection of "sorry, that ship has sailed" which indicates an agenda that
is counter to greater social consensus and status quo. We should not
incentivize such behavior further by allowing this sort of feature
sainthood.

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.


Removing the mempoolfullrbf feature is the opposite of restraining user
choice.

First, any incentivized user can still create and distribute patches for
any given mempool policy, regardless of whether we remove the feature from
Core, but it is important to note that extremely few have felt the need to
do so in the past.

Second, the very debate here is about how it is mempoolfullrbf that removes
the user choice of zero-conf services. With a first-seen policy in place,
users have *more* options, and Bitcoin is thus more useful, and thus more
valuable to everyone. This is evident in that the feature of full-rbf is
that it overrides any ability for users to signal intent of how they wish
their transaction to be handled by nodes and miners. This is useful info to
miners, as they make more money by facilitating use cases than by
fee-minimizers painting everything as RBF. User-signaling is a useful
feature for the mempool, full-RBF removes that feature.

Third, when Bitcoin Core adds special support for specific policies, it
positions itself as a political authority and influencer. It is not Core's
place to support one subjective policy more than another, particularly when
it conflicts with years of status quo and breaks the current user space,
and likely resulting in more doublespent user experiences.

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


I am particularly skeptical that users sending Bitcoin to themselves
(coinjoin) could ever be more incentive-compatible than fast-paced commerce
& priority competition. I am also skeptical that mempoolfullrbf actually
solves LN risks any better than opt-in RBF by default by LN implementations
and wallets.

Further, zero-conf support reduces friction for LN adoption by allowing us
to make instant, seamless UX within wallets when onboarding, rebalancing,
and splicing.

--
John Carvalho
CEO, Synonym.to <http://synonym.to/>



>
> Date: Fri, 2 Dec 2022 17:35:39 -0500
> From: Antoine Riard <antoine.riard@gmail.com>
> To: Bitcoin Protocol Discussion
>         <bitcoin-dev@lists.linuxfoundation.org>
> Subject: [bitcoin-dev] Fwd: [Opt-in full-RBF] Zero-conf apps in
>         immediate       danger
> Message-ID:
>         <
> CALZpt+HFFwY4XECNZj3XLqnaumPeDjrwvnCsRa3vsGQfuXn8wA@mail.gmail.com>
> 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
>

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

<div dir=3D"ltr"><div>Antoine,</div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">In the direction of removing the current option=
 from Bitcoin Core, I think the prerequisite to address are the qualificati=
on of enough economic flows at risk and the presence of a sizable loss in m=
iners income.=C2=A0</blockquote><div dir=3D"ltr"><br></div><div>Are such pr=
erequisites for feature removal published somewhere? I don&#39;t see any re=
ason why removing a controversial change should=C2=A0be harder than adding =
one. Generally, it is impossible to definitively attribute any change in ne=
twork condition to one thing in such a complex system, and also difficult t=
o know how much time is required to express negative effects. The whole arg=
ument here is to prevent disruption of the status quo that has lasted the w=
hole history of Bitcoin, to avoid taking a speculative risk that full-RBF, =
at the expense of zero-conf, is maybe better for miners... or something.</d=
iv><div><br></div><div>Further, I feel the mempoolfullrbf=C2=A0feature was =
rushed through while this controversy was growing, specifically to attempt =
to achieve this imaginary protection of &quot;sorry, that ship has sailed&q=
uot; which indicates an agenda that is counter to greater social consensus =
and status quo. We should not incentivize such behavior further by allowing=
 this sort of feature sainthood.=C2=A0</div><div><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">Beyond that, I think there is still the o=
pen question if we (we, as the Bitcoin protocol development community, with=
 all its stakeholders) should restrain user choice in policy settings in th=
e name of preserving mining income and established use-case stability.</blo=
ckquote><div dir=3D"ltr"><br></div><div>Removing the mempoolfullrbf feature=
 is the opposite of restraining user choice.=C2=A0</div><div><br></div><div=
>First, any incentivized user can still create and distribute patches for a=
ny given mempool policy, regardless of whether we remove the feature from C=
ore, but it is important to note that extremely few have felt the need to d=
o so in the past.</div><div><br></div><div>Second, the very debate here is =
about how it is mempoolfullrbf that removes the user choice of zero-conf se=
rvices. With a first-seen policy in place, users have *more* options, and B=
itcoin is thus more useful, and thus more valuable to everyone. This is evi=
dent in that the feature of full-rbf is that it overrides any ability for u=
sers to signal intent of how they wish their transaction to be handled by n=
odes and miners. This is useful info to miners, as they make more money by =
facilitating use cases than by fee-minimizers painting everything as RBF. U=
ser-signaling is a useful feature for the mempool, full-RBF removes that fe=
ature.</div><div><br></div><div>Third, when Bitcoin Core adds special suppo=
rt for specific policies, it positions itself as a political authority and =
influencer. It is not Core&#39;s place to support one subjective policy mor=
e than another, particularly when it conflicts with years of status quo and=
 breaks the current user space, and likely resulting in more doublespent us=
er experiences.</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">To recall, the original technical motivation of this option, and=
 the wider smoother deployment was to address a DoS vector affecting anothe=
r 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 sol=
ve this DoS vector have been devised, all with their own trade-offs and con=
ceptual issues [4] [5].</blockquote><div dir=3D"ltr"><br></div><div dir=3D"=
ltr">I am particularly skeptical that users sending Bitcoin to themselves (=
coinjoin) could ever be more incentive-compatible than fast-paced commerce =
&amp; priority competition. I am also skeptical that mempoolfullrbf actuall=
y solves LN risks any better than opt-in RBF by default by LN implementatio=
ns and wallets.=C2=A0</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">Furt=
her, zero-conf support reduces friction for LN adoption by allowing us to m=
ake instant, seamless UX within wallets when onboarding, rebalancing, and s=
plicing.=C2=A0</div><div dir=3D"ltr"><br clear=3D"all"><div><div dir=3D"ltr=
" class=3D"gmail_signature"><div dir=3D"ltr"><span style=3D"color:rgb(34,34=
,34)">--</span><br style=3D"color:rgb(34,34,34)"><div dir=3D"ltr" style=3D"=
color:rgb(34,34,34)"><div dir=3D"ltr">John Carvalho</div><div dir=3D"ltr">C=
EO,=C2=A0<a href=3D"http://synonym.to/" style=3D"color:rgb(17,85,204)" targ=
et=3D"_blank">Synonym.to</a><br><div><br></div></div></div></div></div></di=
v></div><br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><br><br>
Date: Fri, 2 Dec 2022 17:35:39 -0500<br>
From: Antoine Riard &lt;<a href=3D"mailto:antoine.riard@gmail.com" target=
=3D"_blank">antoine.riard@gmail.com</a>&gt;<br>
To: Bitcoin Protocol Discussion<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&g=
t;<br>
Subject: [bitcoin-dev] Fwd: [Opt-in full-RBF] Zero-conf apps in<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 immediate=C2=A0 =C2=A0 =C2=A0 =C2=A0danger<br>
Message-ID:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;<a href=3D"mailto:CALZpt%2BHFFwY4XECNZj3XLq=
naumPeDjrwvnCsRa3vsGQfuXn8wA@mail.gmail.com" target=3D"_blank">CALZpt+HFFwY=
4XECNZj3XLqnaumPeDjrwvnCsRa3vsGQfuXn8wA@mail.gmail.com</a>&gt;<br>
Content-Type: text/plain; charset=3D&quot;utf-8&quot;<br>
<br>
Hi Daniel,<br>
<br>
&gt;From my understanding of GAP600, you&#39;re operating a zero-conf risk =
analysis<br>
business, which is integrated and leveraged by payment processors/liquidity=
<br>
providers and merchants. A deployment of fullrbf by enough full-node<br>
operators and a subset of the mining hashrate would lower the cost of<br>
double-spend attack by lamda users, therefore increasing the risk exposure<=
br>
of your users. This increased risk exposure could lead you to alter the<br>
acceptance of incoming zero-conf transactions, AFAICT in a similar<br>
reasoning as exposed by Bitrefill earlier this year [0].<br>
<br>
About the statistics you&#39;re asking for considerations, few further<br>
questions, on those 1.5M transactions per month, a) how many are<br>
Bitcoin-only (as I understand to be multi-cryptocurrencies), b) how many<br=
>
are excluded from zeroconf due to factors like RBF, long-chain of<br>
unconfirmed ancestors or too high-value and c) what has been the average<br=
>
feerate (assuming a standard size of 200 bytes) ?<br>
<br>
My personal position on fullrbf is still the same as expressed in #26525<br=
>
[1]. As a community, I think we still don&#39;t have conceptual consensus o=
n<br>
deploying full-rbf, nor to remove it. In the direction of removing the<br>
current option from Bitcoin Core, I think the prerequisite to address are<b=
r>
the qualification of enough economic flows at risk and the presence of a<br=
>
sizable loss in miners income. Beyond that, I think there is still the open=
<br>
question if we (we, as the Bitcoin protocol development community, with all=
<br>
its stakeholders) should restrain user choice in policy settings in the<br>
name of preserving mining income and established use-case stability.<br>
<br>
To recall, the original technical motivation of this option, and the wider<=
br>
smoother deployment was to address a DoS vector affecting another class of<=
br>
use-case: multi-party transactions like coinjoin and contracting protocols<=
br>
like Lightning [2] [3]. All of them expect to generate economic flows and<b=
r>
corresponding mining income. Since then, alternative paths to solve this<br=
>
DoS vector have been devised, all with their own trade-offs and conceptual<=
br>
issues [4] [5].<br>
<br>
Best,<br>
Antoine<br>
</blockquote></div></div>

--000000000000a4330a05ef17fcf4--