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
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
|
Return-Path: <jlrubin@mit.edu>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id C29EBC000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 28 Jan 2022 01:35:27 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id A38C960B20
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 28 Jan 2022 01:35:27 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level:
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5
tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Jkkxo7XMDAkw
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 28 Jan 2022 01:35:26 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
by smtp3.osuosl.org (Postfix) with ESMTPS id 53B9860AFC
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 28 Jan 2022 01:35:26 +0000 (UTC)
Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com
[209.85.167.52]) (authenticated bits=0)
(User authenticated as jlrubin@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 20S1ZNrB028414
(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 27 Jan 2022 20:35:24 -0500
Received: by mail-lf1-f52.google.com with SMTP id y15so8713925lfa.9
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Jan 2022 17:35:24 -0800 (PST)
X-Gm-Message-State: AOAM531WWhHqqr/BK+Yff5HQdvuBG7dDFJbBDbH3Up518XSqA/XOLlpm
NJsE9MC5Rux3Hk1gVPFPlPbFcKAP7kG+EaOc4hQ=
X-Google-Smtp-Source: ABdhPJzu7aflrEwDXj/mSo1D/O85fgjPxh/A8E/V/nGdLW11/Yd1ZjRE4FeYxbRbqf+EKJGb8oJYJtRNEreEBX1mZaQ=
X-Received: by 2002:a05:6512:31cf:: with SMTP id
j15mr4534286lfe.670.1643333722827;
Thu, 27 Jan 2022 17:35:22 -0800 (PST)
MIME-Version: 1.0
References: <CAFXO6=LGbaur6XQrE+6a6mAAHXduOCXoWPTgPosxAG59ZkK6Gg@mail.gmail.com>
In-Reply-To: <CAFXO6=LGbaur6XQrE+6a6mAAHXduOCXoWPTgPosxAG59ZkK6Gg@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Thu, 27 Jan 2022 17:35:11 -0800
X-Gmail-Original-Message-ID: <CAD5xwhj=yc5g0NBG0ScNvNs-8pUWDFoGn1GZkqezX1_5e+4LKg@mail.gmail.com>
Message-ID: <CAD5xwhj=yc5g0NBG0ScNvNs-8pUWDFoGn1GZkqezX1_5e+4LKg@mail.gmail.com>
To: Gloria Zhao <gloriajzhao@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000cbf31d05d69a72cb"
Subject: Re: [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: Fri, 28 Jan 2022 01:35:27 -0000
--000000000000cbf31d05d69a72cb
Content-Type: text/plain; charset="UTF-8"
Gloria,
This is a brilliant post! Great job systematizing many of the issues. Quite
a lot to chew on & I hope other readers of this list digest the post fully.
Three things come to mind as partial responses:
under:
- **DoS Protection**: Limit two types of DoS attacks on the node's
> mempool: (1) the number of times a transaction can be replaced and
> (2) the volume of transactions that can be evicted during a
> replacement.
I'd more simply put it:
Limiting the amount of work that must be done to consider the replacement
We don't particularly care about goal (1) or goal (2), we care about how
much it costs to do (1) or (2). And there are scenarios where the (1) or
(2) might not be particularly high, but the total work still might be. I
can give you some examples to consider if needed. There are also scenarios
where (1) and (2) might be high, but the cost is low overall. Therefore it
makes sense to be a little more general with what the anti-DoS goal is.
An issue I'd like to toss into the mix is that of iterative / additive
batching. E.g., https://bitcoinops.org/en/cardcoins-rbf-batching/
This is where an business puts a txn in the mempool that pays to N users,
and as they see additional requests for payouts the update it to N+2,
N+2... N+M payouts. This iterative batching can be highly efficient because
the number of transactions per business per 10 minutes is 1 (with variable
number of outputs).
One issue with this approach today is that because of the feerate rule, if
you go from N to N+1 you need to pay 1 sat/byte over the whole txn. Applied
M times, and you have to increase fees quadratically for this approach.
Therefore the less efficient long-chain of batches model ends up being
'rational' with respect to mempool policy and irrational with respect to
"optimally packing blocks with transactions".
If the absolute fee rule is dropped, but feerate remains, one thing you
might see is businesses doing iterative batches with N+2M outputs whereby
they drop 2 outputs for every input they add, allowing the iterative batch
to always increase the fee-rate but possibly not triggering the quadratic
feerate issue since the transaction gets smaller over time.
Another possible solution to this would be to allow relaying "txdiffs"
which only require re-relay of signatures + new/modified outputs, and not
the entire tx.
I think this iterative batching is pretty desirable to support, and so I'd
like to see a RBF model which doesn't make it "unfairly" expensive.
(I'll spare everyone the details on how CTV batching also solves this, but
feel free to ask elsewhere.)
A counterargument to additive batching is that if you instead do non
iterative batches every minute, and you have 100 txns that arrive
uniformly, you'd end up with 10 batches of size 10 on average. The bulk of
the benefit under this model is in the non-batched to batched transition,
and the iterative part only saves on space/fees marginally after that point.
A final point is that a verifiable delay function could be used over, e.g.,
each of the N COutpoints individually to rate-limit transaction
replacement. The VDF period can be made shorter / eliminated depending on
the feerate increase. E.g., always consider a much higher feerate txn
whenever available, for things of equal feerate only consider 1 per minute.
A VDF is like proof-of-work that doesn't parallelize, in case you are
unfamiliar, so no matter how many computers you have it would take about
the same amount of time (you could parallelize across N outputs, of course,
but you're still bound minimally to the time it takes to replace 1 output,
doing all outputs individually just is the most flexible option).
Cheers,
Jeremy
--000000000000cbf31d05d69a72cb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Gloria,<=
/div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00=
0000">This is a brilliant post! Great job systematizing many of the issues.=
Quite a lot to chew on & I hope other readers of this list digest the =
post fully.</div><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"g=
mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:#000000">Three things come to mind as partial responses:</div><div=
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:#000000"><br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">u=
nder:</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetic=
a,sans-serif;font-size:small;color:#000000"><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><spa=
n style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif">- **=
DoS Protection**: Limit two types of DoS attacks on the node's<br></spa=
n><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif=
">=C2=A0 mempool: (1) the number of times a transaction can be replaced and=
<br></span><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,s=
ans-serif">(2) the volume of transactions that can be evicted during a<br><=
/span><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-s=
erif">replacement.</span></blockquote><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br>=
</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:#000000">I'd more simply put it:</div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:#000000"><br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">L=
imiting the amount of work that must be done to consider the replacement</d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0000=
00">We don't particularly=C2=A0care about goal (1) or goal (2), we care=
about how much it costs to do (1) or (2). And there are scenarios where th=
e (1) or (2) might not be particularly high, but the total work still might=
be. I can give you some examples to consider if needed. There are also sce=
narios where (1) and (2) might be high, but the cost is low overall. Theref=
ore=C2=A0it makes sense to be a little more general with what the anti-DoS =
goal is.</div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:#000000">An iss=
ue I'd like to toss into the mix is that of iterative / additive batchi=
ng. E.g., <a href=3D"https://bitcoinops.org/en/cardcoins-rbf-batching/">htt=
ps://bitcoinops.org/en/cardcoins-rbf-batching/</a></div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:#000000">This is where an b=
usiness puts a txn in the mempool that pays to N users, and as they see add=
itional requests for payouts the update it to N+2, N+2... N+M payouts. This=
iterative batching can be highly efficient because the number of transacti=
ons per business per 10 minutes is 1 (with variable number of outputs).</di=
v><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00000=
0">One issue with this approach today is that because of the feerate rule, =
if you go from N to N+1 you need to pay 1 sat/byte over the whole txn. Appl=
ied M times, and you have to increase fees quadratically for this approach.=
Therefore the less efficient long-chain of batches model ends up being =
9;rational' with respect to mempool policy and irrational with respect =
to "optimally packing blocks with transactions".=C2=A0</div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">If t=
he absolute fee rule is dropped, but feerate remains, one thing you might s=
ee is businesses doing iterative batches with N+2M outputs whereby they dro=
p 2 outputs for every input they add, allowing the iterative batch to alway=
s increase the fee-rate but possibly not=C2=A0triggering the quadratic feer=
ate issue since the transaction gets smaller over time.</div><div class=3D"=
gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:#000000">Another possi=
ble solution to this would be to allow relaying "txdiffs" which o=
nly require re-relay of signatures=C2=A0+ new/modified outputs, and not the=
entire tx.</div><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"g=
mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:#000000">I think this iterative batching is pretty desirable to su=
pport, and so I'd like to see a RBF model which doesn't make it &qu=
ot;unfairly" expensive.=C2=A0</div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><=
br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:#000000">(I'll spare everyone the deta=
ils on how CTV batching also solves this, but feel free to ask elsewhere.)<=
/div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00=
0000">A counterargument to additive batching is that if you instead do non =
iterative batches every minute, and you have 100 txns that arrive uniformly=
, you'd end up with 10 batches of size 10 on average. The bulk of the b=
enefit under this model is in the non-batched to batched transition, and th=
e iterative part only saves on space/fees marginally after that point.</div=
><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000=
"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:#000000">A final point is that a verifiable delay function could be use=
d over, e.g., each of the N COutpoints individually to rate-limit transacti=
on replacement. The VDF period can be made shorter / eliminated depending o=
n the feerate increase. E.g., always consider a much higher feerate txn whe=
never available, for things of equal feerate only consider 1 per minute. A =
VDF is like proof-of-work that doesn't parallelize, in case you are unf=
amiliar, so no matter how many computers you have it would take about the s=
ame amount of time (you could parallelize across N outputs, of course, but =
you're still bound minimally to the time it takes to replace 1 output, =
doing all outputs individually just is the most flexible option).=C2=A0</di=
v><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00000=
0"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:#000000">Cheers,</div><div class=3D"gm=
ail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:#000000">Jeremy</div></d=
iv></div>
--000000000000cbf31d05d69a72cb--
|