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
|
Return-Path: <rhavar@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A6CB3F54
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Feb 2018 17:30:12 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A93A02F6
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Feb 2018 17:30:10 +0000 (UTC)
Date: Mon, 12 Feb 2018 12:30:04 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1518456606;
bh=+2bhF6vxNszyKB154cOLocXMwD574KoV0K6jz0LB6DA=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=yCNrpu3iDzr27RuHvOCyTi3UsHDTrXbeDc/T59TGu/qCLHcSV7A9wUy4tYyOVmm+P
aW8PsxkOMjv8u6VGo9qPnVJvwyWga1fZcheeyT/pOD/rdNvPmqUk21l67WLBnZbGmy
ZAA0thSW8F0i/tfocOdnV8tXgE1wl7slkngqZSso=
To: Russell O'Connor <roconnor@blockstream.io>
From: rhavar@protonmail.com
Reply-To: rhavar@protonmail.com
Message-ID: <7zJRAGZXWFiiXu-S3UliZqtP1crDG6s8MDEOurJrXXJc0BkZxw8o0zcGh7DthtvczMxoQHKZ6PwQsZJ0s403noMah26S2xAdGBX2NNL1OfI=@protonmail.com>
In-Reply-To: <CAMZUoKnGx3p7=Kg96E3EEyJ8aFC7ezsvec_pAnN7oJz7-VbyLA@mail.gmail.com>
References: <CAMZUoKnGx3p7=Kg96E3EEyJ8aFC7ezsvec_pAnN7oJz7-VbyLA@mail.gmail.com>
Feedback-ID: RdfuD--Ffc-FNb_4UIG1XA3s5stj1f6Yt84KENdha_3WoiW3STYpu7X5uGR72LvTfQZpxEhSRHGSlNfV5XM5RA==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 12 Feb 2018 17:39:42 +0000
Cc: "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [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 17:30:12 -0000
Thank you very much for writing this up.=C2=A0 It's worth noting that there=
can be multiple roots for the transactions that are getting replaced.
So for rule 3, you probably want a feeRate >=3D the max "package fee rate" =
of all replaced roots.
I am very happy with this proposal in general, as it's clearly a step in th=
e right direction for making transaction replacement practically usable for=
todays services.
However, I think your new rule 4 is a bit weak. The logical extension of yo=
ur proposal would be to allow a transaction (say B) be able to replace tran=
sactions (say A) by purely paying a higher fee rate, /even if it's less abs=
olute fee/. In this simple example of B replacing A -- B should pay at leas=
t: (a.FeeRate * b.size) + relayFeeRate*(a.size + b.size)
=E2=80=8B-Ryan
=E2=80=8B
-------- Original Message --------
On February 12, 2018 10:52 AM, Russell O'Connor via bitcoin-dev <bitcoin-d=
ev@lists.linuxfoundation.org> wrote:
>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, sometim=
es one's transaction becomes pinned making it infeasible to fee bump with R=
BF.=C2=A0 This happens when one makes a normal payment to a large commercia=
l service, and, while the transaction remains unconfirmed, the commercial s=
ervice 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 ge=
t confirmation of the change output for use in further transactions, the cu=
rrent BIP 125 rules require that you make a fee bump that exceeds the combi=
ned total fees of the original transaction and the low-fee-rate sweep of th=
e 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 origina=
l transaction.=C2=A0 BIP 125 was defined back in 2015, when perhaps rationa=
l miners did care about absolute fee amounts. However, today we are in an e=
ra where rational miners care about fee-rates more than absolute fees.=
=C2=A0 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.=C2=A0 Today, a rational miner will prefer a fee-bumped versio=
n of original transaction without consideration of the low-fee sweep transa=
ction (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=20
>>that did not previously appear in the mempool. (Unconfirmed inputs are=20
>>inputs spending outputs from currently unconfirmed transactions.)
>>
>>3. The replacement transaction pays an absolute fee of at least the sum p=
aid 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=
=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.
>>
>>5. 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.
>>
>>To address the new reality of rational miners' consideration, I propose c=
hanging 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 transact=
ions 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 an=
d 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 trans=
actions.
>Rule 3' is a fancy way of saying that the replacement transaction must hav=
e a fee rate that is larger than the package fee rate of the root of the se=
t of transactions it replaces, where the package fee rate is the fee rate i=
mplied 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 f=
or the size of the original transactions being evicted, but some people I c=
hatted with thought it could be important.
>
>Other people on the mailing list have been thinking about RBF policy for f=
ar longer than I have, so I wouldn't be surprised if my proposal above is n=
aive.=C2=A0 However, I think it can start a conversation about addressing t=
he problems with the current RBF policy.
>
|
