Date: Wed, 2 Nov 2022 13:07:45 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Greg Sanders <gsanders87@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Y2HfAVTgj6qZb49q@erisian.com.au>
References: <Y1nIKjQC3DkiSGyw@erisian.com.au>
 <CAFp6fsFm06J2G1=3ojQvcL9gbEbQ41C4rmf3=Jkm9Qm0VBhhKw@mail.gmail.com>
 <CAB3F3Dt=2hDXXw6Jz9QwnotkNLyGdZn9GZLHFXu0Dnyz3tsc0w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAB3F3Dt=2hDXXw6Jz9QwnotkNLyGdZn9GZLHFXu0Dnyz3tsc0w@mail.gmail.com>
Subject: Re: [bitcoin-dev] On mempool policy consistency
Precedence: list

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