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
156
157
158
159
160
161
162
163
|
Return-Path: <bram@chia.net>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 0857AC000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 31 Jan 2022 22:54:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id EAD91401E1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 31 Jan 2022 22:54:24 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=chia.net
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 WNcM-E36YVgD
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 31 Jan 2022 22:54:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com
[IPv6:2a00:1450:4864:20::12d])
by smtp2.osuosl.org (Postfix) with ESMTPS id AE21A40189
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 31 Jan 2022 22:54:23 +0000 (UTC)
Received: by mail-lf1-x12d.google.com with SMTP id u14so29968954lfo.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 31 Jan 2022 14:54:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chia.net; s=google;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=qgy8/XteBjEhyDsBlgst+qCujeSVEaVXJB30w1I6QJo=;
b=W7+GIsHqncjy61OnDlHVcsc5rE1OKVSxNNF851LOLYZ4jv+Wwu0UQL0AUzBDo1znBr
hJXfzrlU06OM+5XRkzyelI8upP7ydyy286FAPuGDnB+bpAsn4qgbJryPqN+xKjsgPg/B
UglLsiAW/NeS48Dtd/ZgC6oUFf69N8Uy8WMJeRtBhKmSIYPNrlVockFrnt15P14zJjnl
YlgygVoUaDa8U5iHx6gYe+hQ9MuTW472eQhNr9ct7cYVR3qx/ZfYfDQGsY8cgcGoha+G
K/Tj6d4kFhEqKwwdqczQzDJbd+2ARbkvdA93XgPAaOt0ajb6ZwmvSIoi3cAs0UiZM4jv
PCUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=qgy8/XteBjEhyDsBlgst+qCujeSVEaVXJB30w1I6QJo=;
b=2KliLd9hzJOwn/6JO62aP9VjLGR6l9E0mUafSyQ9Qtkl4QmNGLwAs1dbRGdztA3PkI
yCc60uQXsacuG5UFR6kS8fWRw5Z2b/BQmai4/PZ+lf8jMkrD+tQs/6IBB8rkLgz2bmp8
nbRMs5dmxFW6dLMwPKrYCjkZ9GjFuRrzO4IW90+GBxtZt/ydit+dKBJBOdcFFz6QCOdh
rOTpyrxnvw5jT4WUbKd7NHbYpIRG8mSR2r6EuI0FleCFyyT8gdYZPyMBBMbVWaXP/BAh
Ipp9M5Ox8aGScHS5uniwnHvEZTMpwKqXURmW4NkfDNcV+VGW0OQbSv0FD4B1wXZodhqn
H89Q==
X-Gm-Message-State: AOAM5305iEjafn3QSLlKKrRXb3OrR8wWo+8LTwJ/fTF3e28wkMFlyCvn
DdOY67Fqdo+9DCpMaS+58wdz0VTGGC9LdBG73Q7umzXNHVE=
X-Google-Smtp-Source: ABdhPJyUtfhJM1EwW7rNxeHS3dXZhAPQ2kEG3Z/CSgxKePZJkT8ESihqfyvpfmlr2i8Q4GxI8aM2Adwm4AxF+1Dmfqo=
X-Received: by 2002:a05:6512:11ef:: with SMTP id
p15mr16386791lfs.471.1643669661296;
Mon, 31 Jan 2022 14:54:21 -0800 (PST)
MIME-Version: 1.0
References: <mailman.19693.1643292568.8511.bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <mailman.19693.1643292568.8511.bitcoin-dev@lists.linuxfoundation.org>
From: Bram Cohen <bram@chia.net>
Date: Mon, 31 Jan 2022 14:54:10 -0800
Message-ID: <CAHUJnBA7AtX_osJUJQyKmc5QBknH5U0TKU3hiyxzpPv4TN88JQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000004a40a605d6e8aa4e"
X-Mailman-Approved-At: Mon, 31 Jan 2022 23:15:32 +0000
Subject: [bitcoin-dev] Improving RBF policy
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, 31 Jan 2022 22:54:25 -0000
--0000000000004a40a605d6e8aa4e
Content-Type: text/plain; charset="UTF-8"
Gloria Zhao wrote:
>
> This post discusses limitations of current Bitcoin Core RBF policy and
> attempts to start a conversation about how we can improve it,
> summarizing some ideas that have been discussed. Please reply if you
> have any new input on issues to be solved and ideas for improvement!
>
Is it still verboten to acknowledge that RBF is normal behavior and
disallowing it is the feature, and that feature is mostly there to appease
some people's delusions that zeroconf is a thing? It seems a bit overdue to
disrespect the RBF flag in the direction of always assuming it's on.
> - **Incentive Compatibility**: Ensure that our RBF policy would not
> accept replacement transactions which would decrease fee profits
> of a miner. In general, if our mempool policy deviates from what is
> economically rational, it's likely that the transactions in our
> mempool will not match the ones in miners' mempools, making our
> fee estimation, compact block relay, and other mempool-dependent
> functions unreliable. Incentive-incompatible policy may also
> encourage transaction submission through routes other than the p2p
> network, harming censorship-resistance and privacy of Bitcoin payments.
>
There are two different common regimes which result in different
incentivized behavior. One of them is that there's more than a block's
backlog in the mempool in which case between two conflicting transactions
the one with the higher fee rate should win. In the other case where there
isn't a whole block's worth of transactions the one with higher total value
should win. It would be nice to have consolidated logic which handles both,
it seems the issue has to do with the slope of the supply/demand curve
which in the first case is gentle enough to keep the one transaction from
hitting the rate but in the second one is basically infinite.
--0000000000004a40a605d6e8aa4e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr">Gloria Zhao wrote:</div><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
This post discusses limitations of current Bitcoin Core RBF policy and<br>
attempts to start a conversation about how we can improve it,<br>
summarizing some ideas that have been discussed. Please reply if you<br>
have any new input on issues to be solved and ideas for improvement!<br></b=
lockquote><div><br></div><div>Is it still verboten to acknowledge that RBF =
is normal behavior and disallowing it is the feature, and that feature is m=
ostly there to appease some people's delusions that zeroconf is a thing=
? It seems a bit overdue to disrespect the RBF flag in the direction of alw=
ays assuming it's on.</div><div>=C2=A0</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">- **Incentive Compatibility**: Ensure that our RBF p=
olicy would not<br>
=C2=A0 accept replacement transactions which would decrease fee profits<br>
=C2=A0 of a miner. In general, if our mempool policy deviates from what is<=
br>
economically rational, it's likely that the transactions in our<br>
mempool will not match the ones in miners' mempools, making our<br>
fee estimation, compact block relay, and other mempool-dependent<br>
functions unreliable. Incentive-incompatible policy may also<br>
encourage transaction submission through routes other than the p2p<br>
network, harming censorship-resistance and privacy of Bitcoin payments.<br>=
</blockquote><div><br></div><div>There are two different common regimes whi=
ch result in different incentivized behavior. One of them is that there'=
;s more than a block's backlog in the mempool in which case between two=
conflicting transactions the one with the higher fee rate should win. In t=
he other case where there isn't a whole block's worth of transactio=
ns the one with higher total value should win. It would be nice to have con=
solidated logic which handles both, it seems the issue has to do with the s=
lope of the supply/demand curve which in the first case is gentle enough to=
keep the one transaction from hitting the rate but in the second one is ba=
sically infinite.</div></div></div>
--0000000000004a40a605d6e8aa4e--
|
