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
|
Return-Path: <gsanders87@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id AB908C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 12 May 2022 13:31:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 8BD1D41996
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 12 May 2022 13:31:15 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 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,
FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
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: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 1fXQawgwAUPk
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 12 May 2022 13:31:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yw1-x112b.google.com (mail-yw1-x112b.google.com
[IPv6:2607:f8b0:4864:20::112b])
by smtp4.osuosl.org (Postfix) with ESMTPS id 410D741987
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 12 May 2022 13:31:14 +0000 (UTC)
Received: by mail-yw1-x112b.google.com with SMTP id
00721157ae682-2f7d7e3b5bfso56520687b3.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 12 May 2022 06:31:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=aFYEuaCTC3t5vxoyNIE4qHCl/s4uUvDyVinhU12Fj7U=;
b=PDkwdzo57gW1tdREf7JWayP3qo2Jq1E+Zu81M/WN02PEzF5mY3XGuHqgbh+0hbIbKR
+WTcbnMgNMHha0GDCUAC+MigxcqfnFVb1PAyAzuS9L6OIZyvqxD16z4O/mdG+TkeIm+m
XNxlgOrRbwEhKz2PcK4o5O6eUK7o5m2e0FBA4GepY5UXexi7r7IkqIJOM1NAei+zDJG7
IyQvBrENvn1kdwC9TbT1mbc4FONUhEjGThJpNn6bRZlqSoas+mskhEHqw24iJeOJRLAj
ppN1N6DLqWekPpdZskmRvLK9GqBjkQ/qOQsq6RO4dpf7hFgGgO+PZgTgKkuMNrLXzL9z
WuZQ==
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:cc;
bh=aFYEuaCTC3t5vxoyNIE4qHCl/s4uUvDyVinhU12Fj7U=;
b=W3AIgXaLG6/ihv6/X14+DdrJGVz8nltxSZ3ETdvAkZR3tI2Ljr4oYQeePcc1ZIfUF7
9SydvadAPRxnqtXfOyOdpdSMmPL5gVwUMf6QKMDgeKz6r0SBT1TKabPx7PlTYe5o4c9h
yennRY2vPj2g9y+49uIuH7YqGNU/HoEe+tnH2y8/+q2Boq9niV9wKW04+5ZUC9xYI10Z
NCC2+diigEE5o+3Dbqmo1bxtCR2xhV5bhhRQTIBvL20WRk4s2vXNqhVwlOJ9JnYfCHoA
mXXYffMe/lDtSuhDEa+LiiNxTeqmeTKd85BViEKBzgAWlDlg3Q0SZfiISaIxEO6mfT7k
rwCw==
X-Gm-Message-State: AOAM531YV2V13eboghG8JKzDqA+3SyV+Y01n/mx/SkMh/iEirEBZ4J0o
Cwdjt75eQTlr8F7Vj/XEn9WlI8tX/WufHo42JCQFySVz
X-Google-Smtp-Source: ABdhPJzdOPBQyHJpdynFSYKsA3Gn4sHGyx1hGrpKFR0VRuorJi4EpCbuv+VNH9bLYRzMfEu7yR87eDQ/MCBEUOd5j8w=
X-Received: by 2002:a81:6355:0:b0:2f1:aed6:ad17 with SMTP id
x82-20020a816355000000b002f1aed6ad17mr30795803ywb.381.1652362273040; Thu, 12
May 2022 06:31:13 -0700 (PDT)
MIME-Version: 1.0
References: <CAB3F3Dtp7YQBhLJQbCLpSKau8Hj=5gN4yuGCFN=u=6e1o6o=dA@mail.gmail.com>
<6a73b36724e6134a1cd57ea9277f2779@dtrt.org>
In-Reply-To: <6a73b36724e6134a1cd57ea9277f2779@dtrt.org>
From: Greg Sanders <gsanders87@gmail.com>
Date: Thu, 12 May 2022 09:31:02 -0400
Message-ID: <CAB3F3DsGtqWo5ajc_iBGikFdTFqfMyA2y0-R1vcgFNht6Rb_Sw@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Content-Type: multipart/alternative; boundary="000000000000532cb005ded092b8"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bringing a nuke to a knife fight: Transaction
introspection to stop RBF pinning
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: Thu, 12 May 2022 13:31:15 -0000
--000000000000532cb005ded092b8
Content-Type: text/plain; charset="UTF-8"
Great point in this specific case I unfortunately didn't consider! So
basically the design degenerates to the last option I gave, where the
counterparty
can send off N(25) weight-bound packages.
A couple thoughts:
0) Couldn't we relative-time lock update transactions's state input by 1
block as well to close the vector off? People are allowed
one "update transaction package" at a time in mempool, so if detected
in-mempool it can be RBF'd, or in-block can be immediately responded to.
1) other usages of ANYONECANPAY like behavior may not have these issues,
like vault structures.
On Thu, May 12, 2022, 3:17 AM David A. Harding <dave@dtrt.org> wrote:
> On 2022-05-10 08:53, Greg Sanders via bitcoin-dev wrote:
> > We add OPTX_SELECT_WEIGHT(pushes tx weight to stack, my addition to
> > the proposal) to the "state" input's script.
> > This is used in the update transaction to set the upper bound on the
> > final transaction weight.
> > In this same input, for each contract participant, we also
> > conditionally commit to the change output's scriptpubkey
> > via OPTX_SELECT_OUTPUT_SCRIPTPUBKEY and OPTX_SELECT_OUTPUTCOUNT==2.
> > This means any participant can send change back
> > to themselves, but with a catch. Each change output script possibility
> > in that state input also includes a 1 block
> > CSV to avoid mempool spending to reintroduce pinning.
>
> I like the idea! However, I'm not sure the `1 CSV` trick helps much.
> Can't an attacker just submit to the mempool their other eltoo state
> updates? For example, let's assume Bob and Mallory have a channel with
> >25 updates and Mallory wants to prevent update[-1] from being committed
> onchain before its (H|P)TLC timeout. Mallory also has at least 25
> unencumbered UTXOs, so she submits to the mempool update[0], update[1],
> update[...], update[24]---each of them with a different second input to pay
> fees.
>
> If `OPTX_SELECT_WEIGHT OP_TX` limits each update's weight to 1,000
> vbytes[1] and the default node relay/mempool policy of allowing a
> transaction and up to 24 descendants remains, Mallory can pin the
> unsubmitted update[-1] under 25,000 vbytes of junk---which is 25% of
> what she can pin under current mempool policies.
>
> Alice can't RBF update[0] without paying for update[1..24] (BIP125 rule
> #3), and an RBF of update[24] will have its additional fees divided by
> its size plus the 24,000 vbytes of update[1..24].
>
> To me, that seems like your proposal makes escaping the pinning at most
> 75% cheaper than today. That's certainly an improvement---yay!---but
> I'm not sure it eliminates the underlying concern. Also depending on
> the mempool ancestor/descendant limits makes it harder to raise those
> limits in the future, which is something I think we might want to do if
> we can ensure raising them won't increase node memory/CPU DoS risk.
>
> I'd love to hear that my analysis is missing something though!
>
> Thanks!,
>
> -Dave
>
> [1] 1,000 vbytes per update seems like a reasonable value to me.
> Obviously there's a tradeoff here: making it smaller limits the amount
> of pinning possible (assuming mempool ancestor/descendant limits remain)
> but also limits the number and complexity of inputs that may be added.
> I don't think we want to discourage people too much from holding
> bitcoins in deep taproot trees or sophisticated tapscripts.
>
--000000000000532cb005ded092b8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"auto">Great point in this specific case I unfo=
rtunately didn't consider! So basically the design degenerates to the l=
ast option I gave, where the counterparty</div><div dir=3D"auto">can send o=
ff N(25) weight-bound packages.<br><div dir=3D"auto"><br></div><div dir=3D"=
auto">A couple thoughts:</div><div dir=3D"auto"><br></div><div>0) Couldn=
9;t we relative-time lock update transactions's state input by 1 block =
as well to close the vector off? People are allowed</div><div>one "upd=
ate transaction package" at a time in mempool, so if detected in-mempo=
ol it can be RBF'd, or in-block can be immediately responded to.</div><=
div dir=3D"auto">1) other usages of ANYONECANPAY=C2=A0like behavior may not=
have these issues, like vault structures.=C2=A0</div><div dir=3D"auto"><br=
></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">On Thu, May 12, 2022, 3:17 AM David A. Harding <<a href=3D"=
mailto:dave@dtrt.org" rel=3D"noreferrer noreferrer noreferrer noreferrer" t=
arget=3D"_blank">dave@dtrt.org</a>> wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">On 2022-05-10 08:53, Greg Sanders via bitcoin=
-dev wrote:<br>
> We add OPTX_SELECT_WEIGHT(pushes tx weight to stack, my addition to<br=
>
> the proposal) to the "state" input's script.<br>
> This is used in the update transaction to set the upper bound on the<b=
r>
> final transaction weight.<br>
> In this same input, for each contract participant, we also<br>
> conditionally commit to the change output's scriptpubkey<br>
> via OPTX_SELECT_OUTPUT_SCRIPTPUBKEY and OPTX_SELECT_OUTPUTCOUNT=3D=3D2=
.<br>
> This means any participant can send change back<br>
> to themselves, but with a catch. Each change output script possibility=
<br>
> in that state input also includes a 1 block<br>
> CSV to avoid mempool spending to reintroduce pinning.<br>
<br>
I like the idea!=C2=A0 =C2=A0However, I'm not sure the `1 CSV` trick he=
lps much.=C2=A0 <br>
Can't an attacker just submit to the mempool their other eltoo state <b=
r>
updates?=C2=A0 For example, let's assume Bob and Mallory have a channel=
with <br>
=C2=A0>25 updates and Mallory wants to prevent update[-1] from being com=
mitted onchain before its (H|P)TLC timeout.=C2=A0 Mallory also has at least=
25 unencumbered UTXOs, so she submits to the mempool update[0], update[1],=
update[...], update[24]---each of them with a different second input to pa=
y fees.<br>
<br>
If `OPTX_SELECT_WEIGHT OP_TX` limits each update's weight to 1,000 <br>
vbytes[1] and the default node relay/mempool policy of allowing a <br>
transaction and up to 24 descendants remains, Mallory can pin the <br>
unsubmitted update[-1] under 25,000 vbytes of junk---which is 25% of <br>
what she can pin under current mempool policies.<br>
<br>
Alice can't RBF update[0] without paying for update[1..24] (BIP125 rule=
<br>
#3), and an RBF of update[24] will have its additional fees divided by <br>
its size plus the 24,000 vbytes of update[1..24].<br>
<br>
To me, that seems like your proposal makes escaping the pinning at most <br=
>
75% cheaper than today.=C2=A0 That's certainly an improvement---yay!---=
but <br>
I'm not sure it eliminates the underlying concern.=C2=A0 Also depending=
on <br>
the mempool ancestor/descendant limits makes it harder to raise those <br>
limits in the future, which is something I think we might want to do if <br=
>
we can ensure raising them won't increase node memory/CPU DoS risk.<br>
<br>
I'd love to hear that my analysis is missing something though!<br>
<br>
Thanks!,<br>
<br>
-Dave<br>
<br>
[1] 1,000 vbytes per update seems like a reasonable value to me.=C2=A0 <br>
Obviously there's a tradeoff here: making it smaller limits the amount =
<br>
of pinning possible (assuming mempool ancestor/descendant limits remain) <b=
r>
but also limits the number and complexity of inputs that may be added.=C2=
=A0 <br>
I don't think we want to discourage people too much from holding <br>
bitcoins in deep taproot trees or sophisticated tapscripts.<br>
</blockquote></div>
--000000000000532cb005ded092b8--
|
