path: root/d1/bfb1dc22d4f6ef4fecf3dbca0eca5c123253eb

Return-Path: <gsanders87@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C2EABC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  2 Nov 2022 13:33:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id A991741626
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  2 Nov 2022 13:33:04 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org A991741626
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=WUzmXsJw
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level: 
X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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 smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id QNzxXhbXJhUq
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  2 Nov 2022 13:33:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 7A4B341621
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [IPv6:2a00:1450:4864:20::52c])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 7A4B341621
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  2 Nov 2022 13:33:02 +0000 (UTC)
Received: by mail-ed1-x52c.google.com with SMTP id z18so21463244edb.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 02 Nov 2022 06:33:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=jHFAmX7UngdKyooHP5toYd51Ywma3v51WwT3jy7CPho=;
 b=WUzmXsJwpVqNhWMUFnomzTxsqs1Tien01POmJ4kAcPMUbbYEA9si5bCSdZbPyAJZ5h
 0nMoTOABuS00/k7K4y3pl4EyG+WwdQeHpTlpFyf9lh6flpF44Cww7Xyh55wvIG92r8vB
 0uiS0Ufq5y7Cz5UVYCIZMWzrQGNF5/y5INfJIvxNhKDAbDWEerA26J8Ie9GhWv3L5iQ9
 p27rNMFLzgzwyIn1DhJPS7d0cDglU9NWqlpKCizCxbZwfkJLRq8r68euCYUYRI2Qp103
 Wgyo0a+tK+hc9lHkg30O/NZEObXX18gwwzQf3/UzCIzZQ3W4jUFM5TBbKovo72JDV7XQ
 gOsA==
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=jHFAmX7UngdKyooHP5toYd51Ywma3v51WwT3jy7CPho=;
 b=GpBG4boqjn7AdA+kFXR1kjMdYg/Fm2vER5QQH4Uyid6jN82ClJeA4J6IBRGSVf5955
 p1oBvs/NlIpcK+YuW5VEs+dKKhdDGQ2eP386rHNMNjKFJwBKFZCOGsTAnHw6awlLqM35
 2gOXiC1ANcIRxS5u53nwosVnCADlOKD2/fD3N0UoAG4pmSvCpcfLQFtji24l7IyOxUb0
 SeQ+Lhhmq7N4WipVgfoYzjMX3RlCaUHNDN3kSBmg/83tuldOCh1BcIVQMyo1Y7ekqFST
 8J20tQWeXo3IdagX3aO6JWBIVgHLROS0OO3adWXgLWWg3ar6vQWJf7tbSde+x1b+Smpu
 Zy7w==
X-Gm-Message-State: ACrzQf3oNtlrHX0onmTkytm3QdbtOyn9u28WhWbj6UcehgblXEZdqthH
 s804Mlmv12aIPdRycRTKHSZ0VZtAmx3IR6paKQrmGg4MLcg=
X-Google-Smtp-Source: AMsMyM4f7j0B1DEqXhOfi9/23445J0bz+dx+c7ECxHUFpwYH6FDVOHNSD2vz9gpOhSJXpJqE72JkWeBnLZBdujOarXA=
X-Received: by 2002:a05:6402:3487:b0:463:9585:ae40 with SMTP id
 v7-20020a056402348700b004639585ae40mr11925918edc.31.1667395980278; Wed, 02
 Nov 2022 06:33:00 -0700 (PDT)
MIME-Version: 1.0
References: <Y1nIKjQC3DkiSGyw@erisian.com.au>
 <CAFp6fsFm06J2G1=3ojQvcL9gbEbQ41C4rmf3=Jkm9Qm0VBhhKw@mail.gmail.com>
 <CAB3F3Dt=2hDXXw6Jz9QwnotkNLyGdZn9GZLHFXu0Dnyz3tsc0w@mail.gmail.com>
 <Y2HfAVTgj6qZb49q@erisian.com.au>
In-Reply-To: <Y2HfAVTgj6qZb49q@erisian.com.au>
From: Greg Sanders <gsanders87@gmail.com>
Date: Wed, 2 Nov 2022 09:32:49 -0400
Message-ID: <CAB3F3DsHGSv1A6kHq_2F5OkugSxUpvhCWz=MvJLRX=iSxXeBPw@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>
Content-Type: multipart/alternative; boundary="0000000000001ac0cf05ec7ce152"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] On mempool policy consistency
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: Wed, 02 Nov 2022 13:33:04 -0000

--0000000000001ac0cf05ec7ce152
Content-Type: text/plain; charset="UTF-8"

> I think that's a huge oversimplification of "rational" -- otherwise
you might as well say that deliberately pinning txs is also rational,
because it allows the person doing the pinning to steal funds from their
counterparty by forcing a timeout to expire.

To be clear, a pinner is attempting to *not* pay
the most fees, by definition. If we're somehow sure something is a pin,
we should not allow it, because miners rationally do not want it vs
an "honest" bid for fees. V3 design is one attempt to carve out a safe
space for fee bidding. Carving out a safe space for *non-bidding* is not the
same thing.

I think this mostly boils down having knobs or not. I'm fine with knobs
with paternalistic defaults, especially when a non-zero percentage of users
disagree with a value in either direction.

Greg

On Tue, Nov 1, 2022 at 11:07 PM Anthony Towns <aj@erisian.com.au> wrote:

> On Mon, Oct 31, 2022 at 12:25:46PM -0400, Greg Sanders via bitcoin-dev
> wrote:
> > For 0-conf services we have potential thieves who are willing
> > to *out-bid themselves* to have funds come back to themselves. It's not a
> > "legitimate" use-case, but a rational one.
>
> I think that's a huge oversimplification of "rational" -- otherwise
> you might as well say that deliberately pinning txs is also rational,
> because it allows the person doing the pinning to steal funds from their
> counterparty by forcing a timeout to expire.
>
> There's no need for us as developers, or us as node operators, to support
> every use case that some individual might find rational at some point in
> time. After all, it might be individually rational for someone to want the
> subsidy to stop decreasing, or to include 8MB of transactions per block.
>
> Note that it's also straightforwardly rational and incentive compatible
> for miners to not want this patch to be available, under the following
> scenario:
>
>  - a significant number of on-chain txs are for zeroconf services
>  - fee income would be reduced if zeroconf services went away
>    (both directly due to the absence of zeroconf payments, and by
>    reducing mempool pressure, reducing fee income from the on-chain txs
>    that remain)
>  - miners adopting fullrbf would cause zeroconf services to go away,
>    (and won't enable a comparable volume of new services that generates
>    comparable transaction volume)
>  - including the option in core would make other miners adopting
>    fullrbf more likely
>
> I think the first three of those are fairly straightforward and objective,
> at least at this point in time. The last is just a risk; but without
> any counterbalancing benefit, why take it?
>
> Gaining a few thousand sats due to high feerate replacement txs from
> people exploiting zeroconf services for a few months before all those
> services shutdown doesn't make up for the lost fee income over the months
> or years it might have otherwise taken people to naturally switch to
> some better alternative.
>
> Even if fullrbf worked for preventing pinning that likely doesn't directly
> result in much additional fee income: once you know that pinning doesn't
> work, you just don't try it, which means there's no opportunity for
> miners to profit from a bidding war from the pinners counterparties
> repeatedly RBFing their preferred tx to get it mined.
>
> That also excludes second order risks: if you can't do zeroconf with BTC
> anymore, do you switch to ERC20 tokens, and then trade your BTC savings
> for ETH or USDT, and do enough people do that to lower the price of BTC?
> If investors see BTC being less used for payments, does that lower their
> confidence in bitcoin's future, and cause them to sell?
>
> > Removing a
> > quite-likely-incentive-compatible option from the software just
> encourages
> > miners to adopt an additional patch
>
> Why shouldn't miners adopt an additional patch if they want some unusual
> functionality?
>
> Don't we want/expect miners to have the ability to change the code in
> meaningful ways, at a minimum to be able to cope with the scenario where
> core somehow gets coopted and releases bad code, or to be able to deal
> with the case where an emergency patch is needed?
>
> Is there any evidence miners even want this option? Peter suggested
> that some non-signalling replacements were being mined already [0], but
> as far as I can see [1] all of those are simply due to the transaction
> they replaced not having propagated in the first place (or having been
> evicted somehow? hard to tell without any data on the original tx).
>
> [0]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021012.html
> [1] https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1292692367
>
> > 2) Forcing miners to honor fees left on the table with respect to 0-conf,
> > or forcing them to run a custom patchset to go around it, is a step
> > backwards.
>
> As you already acknowledged, any miner that wants this behaviour can just
> pick up the patch (or could run Knots, which already has the feature
> enabled by default). It's simply false to say miners are being forced
> to do anything, no matter what we do here.
>
> If the direction you're facing is one where you're moving towards making
> life easier for people to commit fraud, and driving away businesses
> that aren't doing anyone harm, without achieving anything much else;
> then taking a step backwards seems like a sensible thing to do to me.
>
> (I remain optimistic about coming up with better RBF policy, and willing
> to be gung ho about everyone switching over to it even if it does kill
> off zeroconf, provided it actually does some good and we give people 6
> months or more notice that it's definitely happening and what exactly
> the new rules will be, though)
>
> Cheers,
> aj
>

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

<div dir=3D"ltr"><div>&gt; I think that&#39;s a huge oversimplification of =
&quot;rational&quot; -- otherwise<br></div>you might as well say that delib=
erately pinning txs is also rational,<br>because it allows the person doing=
 the pinning to steal funds from their<br>counterparty by forcing a timeout=
 to expire.<div><br></div><div>To be clear, a pinner is attempting to *not*=
 pay</div><div>the most fees, by definition. If we&#39;re somehow sure some=
thing is a pin,</div><div>we should not allow it, because miners rationally=
 do not want it vs</div><div>an &quot;honest&quot; bid for fees. V3 design =
is one attempt to carve out a safe</div><div>space for fee bidding. Carving=
 out a safe space for *non-bidding* is not the</div><div>same thing.</div><=
div><br></div><div>I think this mostly boils down having knobs or not. I&#3=
9;m fine with knobs with paternalistic defaults, especially when a non-zero=
 percentage of users disagree with a value in either direction.</div><div><=
br></div><div>Greg</div></div><br><div class=3D"gmail_quote"><div dir=3D"lt=
r" class=3D"gmail_attr">On Tue, Nov 1, 2022 at 11:07 PM Anthony Towns &lt;<=
a href=3D"mailto:aj@erisian.com.au">aj@erisian.com.au</a>&gt; wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Oct 31, 2022 a=
t 12:25:46PM -0400, Greg Sanders via bitcoin-dev wrote:<br>
&gt; For 0-conf services we have potential thieves who are willing<br>
&gt; to *out-bid themselves* to have funds come back to themselves. It&#39;=
s not a<br>
&gt; &quot;legitimate&quot; use-case, but a rational one.<br>
<br>
I think that&#39;s a huge oversimplification of &quot;rational&quot; -- oth=
erwise<br>
you might as well say that deliberately pinning txs is also rational,<br>
because it allows the person doing the pinning to steal funds from their<br=
>
counterparty by forcing a timeout to expire.<br>
<br>
There&#39;s no need for us as developers, or us as node operators, to suppo=
rt<br>
every use case that some individual might find rational at some point in<br=
>
time. After all, it might be individually rational for someone to want the<=
br>
subsidy to stop decreasing, or to include 8MB of transactions per block.<br=
>
<br>
Note that it&#39;s also straightforwardly rational and incentive compatible=
<br>
for miners to not want this patch to be available, under the following<br>
scenario:<br>
<br>
=C2=A0- a significant number of on-chain txs are for zeroconf services<br>
=C2=A0- fee income would be reduced if zeroconf services went away<br>
=C2=A0 =C2=A0(both directly due to the absence of zeroconf payments, and by=
<br>
=C2=A0 =C2=A0reducing mempool pressure, reducing fee income from the on-cha=
in txs<br>
=C2=A0 =C2=A0that remain)<br>
=C2=A0- miners adopting fullrbf would cause zeroconf services to go away,<b=
r>
=C2=A0 =C2=A0(and won&#39;t enable a comparable volume of new services that=
 generates<br>
=C2=A0 =C2=A0comparable transaction volume)<br>
=C2=A0- including the option in core would make other miners adopting<br>
=C2=A0 =C2=A0fullrbf more likely<br>
<br>
I think the first three of those are fairly straightforward and objective,<=
br>
at least at this point in time. The last is just a risk; but without<br>
any counterbalancing benefit, why take it?<br>
<br>
Gaining a few thousand sats due to high feerate replacement txs from<br>
people exploiting zeroconf services for a few months before all those<br>
services shutdown doesn&#39;t make up for the lost fee income over the mont=
hs<br>
or years it might have otherwise taken people to naturally switch to<br>
some better alternative.<br>
<br>
Even if fullrbf worked for preventing pinning that likely doesn&#39;t direc=
tly<br>
result in much additional fee income: once you know that pinning doesn&#39;=
t<br>
work, you just don&#39;t try it, which means there&#39;s no opportunity for=
<br>
miners to profit from a bidding war from the pinners counterparties<br>
repeatedly RBFing their preferred tx to get it mined.<br>
<br>
That also excludes second order risks: if you can&#39;t do zeroconf with BT=
C<br>
anymore, do you switch to ERC20 tokens, and then trade your BTC savings<br>
for ETH or USDT, and do enough people do that to lower the price of BTC?<br=
>
If investors see BTC being less used for payments, does that lower their<br=
>
confidence in bitcoin&#39;s future, and cause them to sell?<br>
<br>
&gt; Removing a<br>
&gt; quite-likely-incentive-compatible option from the software just encour=
ages<br>
&gt; miners to adopt an additional patch<br>
<br>
Why shouldn&#39;t miners adopt an additional patch if they want some unusua=
l<br>
functionality?<br>
<br>
Don&#39;t we want/expect miners to have the ability to change the code in<b=
r>
meaningful ways, at a minimum to be able to cope with the scenario where<br=
>
core somehow gets coopted and releases bad code, or to be able to deal<br>
with the case where an emergency patch is needed?<br>
<br>
Is there any evidence miners even want this option? Peter suggested<br>
that some non-signalling replacements were being mined already [0], but<br>
as far as I can see [1] all of those are simply due to the transaction<br>
they replaced not having propagated in the first place (or having been<br>
evicted somehow? hard to tell without any data on the original tx).<br>
<br>
[0] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022=
-October/021012.html" rel=3D"noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/pipermail/bitcoin-dev/2022-October/021012.html</a><br>
[1] <a href=3D"https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1=
292692367" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/=
bitcoin/pull/26287#issuecomment-1292692367</a><br>
<br>
&gt; 2) Forcing miners to honor fees left on the table with respect to 0-co=
nf,<br>
&gt; or forcing them to run a custom patchset to go around it, is a step<br=
>
&gt; backwards.<br>
<br>
As you already acknowledged, any miner that wants this behaviour can just<b=
r>
pick up the patch (or could run Knots, which already has the feature<br>
enabled by default). It&#39;s simply false to say miners are being forced<b=
r>
to do anything, no matter what we do here. <br>
<br>
If the direction you&#39;re facing is one where you&#39;re moving towards m=
aking<br>
life easier for people to commit fraud, and driving away businesses<br>
that aren&#39;t doing anyone harm, without achieving anything much else;<br=
>
then taking a step backwards seems like a sensible thing to do to me.<br>
<br>
(I remain optimistic about coming up with better RBF policy, and willing<br=
>
to be gung ho about everyone switching over to it even if it does kill<br>
off zeroconf, provided it actually does some good and we give people 6<br>
months or more notice that it&#39;s definitely happening and what exactly<b=
r>
the new rules will be, though)<br>
<br>
Cheers,<br>
aj<br>
</blockquote></div>

--0000000000001ac0cf05ec7ce152--