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
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
|
Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8C73BEDE
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Feb 2018 15:52:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f44.google.com (mail-it0-f44.google.com
[209.85.214.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A053D5BA
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Feb 2018 15:52:52 +0000 (UTC)
Received: by mail-it0-f44.google.com with SMTP id 193so4331967iti.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Feb 2018 07:52:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream.io; s=google;
h=mime-version:from:date:message-id:subject:to;
bh=+OBG7e9Y7/xTftHfv32sRo0mSKTMPb8sK5v+NlE5hww=;
b=ooP7N7fqrSLUtQFmJzoRWcJoyAOciE8hGbOmwPrugi0Iaff3oPlRqUeTe94BYIydNr
8jv80NwWFfVbteLVObPQWhIslKyUaC8FkWFaRrnZGBlzqAVoMC9WfiPQe+i2Z6s4qQp7
wl/OaEF55j4ggGW/+wTmcp8YNc6nUanXZgywQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=+OBG7e9Y7/xTftHfv32sRo0mSKTMPb8sK5v+NlE5hww=;
b=bHN0KayAccEpieHfCETj8ZJ7K3HiVh7f2oj4VtpJSnRMvH79MLJW3nQs8O0gI6yKa1
q+2gTaErY+L0izP60aW03lqQuLIeerME/Bh3E1pJvnjJhsjGoqrh5samHFtbYqPwaNoK
GLQA+8J/OjupkGkd1fnMjdx/QB1ZcSLmp+9AsBoVzZGkJJmUWlC+o+vh3aTKPjCVmV30
6fLL30PkPAMY7ObykqHvCxW+OBKeWS1mmqXf1+biS7qSRIMRt7QXna250mp2nBhpYWqW
RoyvmmG+uRFLEMWpWMtOC1eDt2gHDNL/REeZx7KIwgPP/4bLPvfvBmzf333NUhFCEKSJ
y7vw==
X-Gm-Message-State: APf1xPCBjmjiHv6pOObdUMTVYjL6E9zKIruP/l/fVTOhKVFAgtKVCHHL
wM7H9FhnjzkfWhTh35AsMxtXb928kcdycGpbF9WKpZvkcUk=
X-Google-Smtp-Source: AH8x227/S2xLb4n1FXdVVw3GJOCAR0OXBbGw1B4Rk/2TtNgyDyEnLwk2LQ77VJL77iFrp08+fWZZ4nUpDYsuq9160ms=
X-Received: by 10.36.46.23 with SMTP id i23mr5977858ita.55.1518450771508; Mon,
12 Feb 2018 07:52:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.2.120.33 with HTTP; Mon, 12 Feb 2018 07:52:30 -0800 (PST)
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Mon, 12 Feb 2018 10:52:30 -0500
Message-ID: <CAMZUoKnGx3p7=Kg96E3EEyJ8aFC7ezsvec_pAnN7oJz7-VbyLA@mail.gmail.com>
To: "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a114a9d82d87b2b056505def0"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] Revisiting BIP 125 RBF policy.
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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, 12 Feb 2018 15:52:53 -0000
--001a114a9d82d87b2b056505def0
Content-Type: text/plain; charset="UTF-8"
I think it is worth revisiting BIP 125's replace-by-fee policy for when to
replace transactions.
The current policy can be problematic. As noted earlier by Rhavar,
sometimes one's transaction becomes pinned making it infeasible to fee bump
with RBF. This happens when one makes a normal payment to a large
commercial service, and, while the transaction remains unconfirmed, the
commercial service creates a low-fee-rate sweep of one's payment, among a
collection of others. If one wants to RBF this original payment, for
example to get confirmation of the change output for use in further
transactions, the current BIP 125 rules require that you make a fee bump
that exceeds the combined total fees of the original transaction and the
low-fee-rate sweep of the commercial service.
The problem is that, while the fee rate of the sweep is low, the absolute
size of the fee can still be large, making it infeasible to RBF the
original transaction. BIP 125 was defined back in 2015, when perhaps
rational miners did care about absolute fee amounts. However, today we are
in an era where rational miners care about fee-rates more than absolute
fees. The fee-rate of the large sweep transaction is low enough that we do
not expect that miners will be mining it in the same block as the original
transaction. Today, a rational miner will prefer a fee-bumped version of
original transaction without consideration of the low-fee sweep transaction
(or at least discounting the low-fee sweep in proportion to the miner's
hash-rate fraction).
Let me quote the five rules that define the current BIP 125 policy:
One or more transactions currently in the mempool (original transactions)
> will be replaced by a new transaction (replacement transaction) that spends
> one or more of the same inputs if,
>
> 1. The original transactions signal replaceability explicitly or
> through inheritance as described in the above Summary section.
> 2. The replacement transaction does not contain any new unconfirmed
> inputs that did not previously appear in the mempool. (Unconfirmed inputs
> are inputs spending outputs from currently unconfirmed transactions.)
> 3. The replacement transaction pays an absolute fee of at least the
> sum paid by the original transactions.
> 4. The replacement transaction must also pay for its own bandwidth at
> or above the rate set by the node's minimum relay fee setting. For example,
> if the minimum relay fee is 1 satoshi/byte and the replacement transaction
> is 500 bytes total, then the replacement must pay a fee at least 500
> satoshis higher than the sum of the originals.
> 5. The number of original transactions to be replaced and their
> descendant transactions which will be evicted from the mempool must not
> exceed a total of 100 transactions.
>
> To address the new reality of rational miners' consideration, I propose
changing rules 3 and 4 to something like the following.
3'. The replacement transaction pays a fee rate of at least the effective
fee rate of any chain of transactions from the set of original transactions
that begins with the root of the original transaction set.
4'. The replacement transaction must also pay for replacing the original
transactions at or above the rate set by the node's minimum relay fee
setting. For example, if the minimum relay fee is 1 satoshi/byte and the
replacement transaction and the original transactions are 1000 bytes total,
then the replacement must pay a fee at least 1000 satoshis higher than the
fee of the root transaction of the original transactions.
Rule 3' is a fancy way of saying that the replacement transaction must have
a fee rate that is larger than the package fee rate of the root of the set
of transactions it replaces, where the package fee rate is the fee rate
implied by considering CPFP.
Rule 4' is an amended anti-spam rule that is intended to avoid DOS attacks
from churning the mempool. I don't know if it is really necessary to pay
for the size of the original transactions being evicted, but some people I
chatted with thought it could be important.
Other people on the mailing list have been thinking about RBF policy for
far longer than I have, so I wouldn't be surprised if my proposal above is
naive. However, I think it can start a conversation about addressing the
problems with the current RBF policy.
--001a114a9d82d87b2b056505def0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div>I think it is worth revisiting BIP 125'=
s replace-by-fee policy for when to replace transactions.<br><br></div>The =
current policy can be problematic. As noted earlier by Rhavar, sometimes on=
e's transaction becomes pinned making it infeasible to fee bump with RB=
F.=C2=A0 This happens when one makes a normal payment to a large commercial=
service, and, while the transaction remains unconfirmed, the commercial se=
rvice creates a low-fee-rate sweep of one's payment, among a collection=
of others.=C2=A0 If one wants to RBF this original payment, for example to=
get confirmation of the change output for use in further transactions, the=
current BIP 125 rules require that you make a fee bump that exceeds the co=
mbined total fees of the original transaction and the low-fee-rate sweep of=
the commercial service.<br><br></div>The problem is that, while the fee ra=
te of the sweep is low, the absolute size of the fee can still be large, ma=
king it infeasible to RBF the original transaction.=C2=A0 BIP 125 was defin=
ed back in 2015, when perhaps rational miners did care about absolute fee a=
mounts. However, today we are in an era where rational miners care about fe=
e-rates more than absolute fees.=C2=A0 The fee-rate of the large sweep tran=
saction is low enough that we do not expect that miners will be mining it i=
n the same block as the original transaction.=C2=A0 Today, a rational miner=
will prefer a fee-bumped version of original transaction without considera=
tion of the low-fee sweep transaction (or at least discounting the low-fee =
sweep in proportion to the miner's hash-rate fraction).<br><br></div>Le=
t me quote the five rules that define the current BIP 125 policy:<br><br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex"><p>One or more transactions=
currently in the mempool (original
transactions) will be replaced by a new transaction (replacement
transaction) that spends one or more of the same inputs if,
</p><ol><li>The original transactions signal replaceability explicitly or t=
hrough inheritance as described in the above Summary section.</li><li>The
replacement transaction does not contain any new unconfirmed inputs=20
that did not previously appear in the mempool. (Unconfirmed inputs are=20
inputs spending outputs from currently unconfirmed transactions.)</li><li>T=
he replacement transaction pays an absolute fee of at least the sum paid by=
the original transactions.</li><li>The
replacement transaction must also pay for its own bandwidth at or above
the rate set by the node's minimum relay fee setting. For example, if=
=20
the minimum relay fee is 1 satoshi/byte and the replacement transaction=20
is 500 bytes total, then the replacement must pay a fee at least 500=20
satoshis higher than the sum of the originals.</li><li>The number of=20
original transactions to be replaced and their descendant transactions=20
which will be evicted from the mempool must not exceed a total of 100=20
transactions.</li></ol></blockquote>
<div>To address the new reality of rational miners' consideration, I pr=
opose changing rules 3 and 4 to something like the following.<br><br></div>=
<div>3'. The replacement transaction pays a fee rate of at least the ef=
fective fee rate of any chain of transactions from the set of original tran=
sactions that begins with the root of the original transaction set.<br><br>=
4'. The
replacement transaction must also pay for replacing the original transacti=
ons at or above
the rate set by the node's minimum relay fee setting. For example, if=
=20
the minimum relay fee is 1 satoshi/byte and the replacement transaction and=
the original transactions are 1000 bytes total, then the replacement must =
pay a fee at least 1000=20
satoshis higher than the fee of the root transaction of the original transa=
ctions.<br><br></div><div>Rule 3' is a fancy way of saying that the rep=
lacement transaction must have a fee rate that is larger than the package f=
ee rate of the root of the set of transactions it replaces, where the packa=
ge fee rate is the fee rate implied by considering CPFP.<br><br></div><div>=
Rule 4' is an amended anti-spam rule that is intended to avoid DOS atta=
cks from churning the mempool. I don't know if it is really necessary t=
o pay for the size of the original transactions being evicted, but some peo=
ple I chatted with thought it could be important.<br></div><div><br></div><=
div>Other people on the mailing list have been thinking about RBF policy fo=
r far longer than I have, so I wouldn't be surprised if my proposal abo=
ve is naive.=C2=A0 However, I think it can start a conversation about addre=
ssing the problems with the current RBF policy.<br></div></div>
--001a114a9d82d87b2b056505def0--
|
