1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
|
Return-Path: <aj@erisian.com.au>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id DF444C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 2 Nov 2022 03:07:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id B329D40236
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 2 Nov 2022 03:07:55 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org B329D40236
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,
UNPARSEABLE_RELAY=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 AcVAqsgZ65hq
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 2 Nov 2022 03:07:54 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 69FE2400DD
Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193])
by smtp2.osuosl.org (Postfix) with ESMTPS id 69FE2400DD
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 2 Nov 2022 03:07:54 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
id 1oq46Y-0004ql-7q; Wed, 02 Nov 2022 13:07:51 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Wed, 02 Nov 2022 13:07:45 +1000
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
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 03:07:56 -0000
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
|
