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
Precedence: list

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