summaryrefslogtreecommitdiff
path: root/fd/9111691d53bb7508fd3017b9d39d54fb4c4734
blob: 0f98c9bdcd2ad4bece84219c09682c4457872627 (plain)
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
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
Return-Path: <antoine.riard@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7C654C000B;
 Fri, 23 Apr 2021 15:39:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 6A1C6400A7;
 Fri, 23 Apr 2021 15:39:31 +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, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
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 VduKLq52AbQi; Fri, 23 Apr 2021 15:39:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com
 [IPv6:2a00:1450:4864:20::429])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 2256A400D7;
 Fri, 23 Apr 2021 15:39:29 +0000 (UTC)
Received: by mail-wr1-x429.google.com with SMTP id p6so42158496wrn.9;
 Fri, 23 Apr 2021 08:39:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=4CPsG5NQB1SZkSubcvaRzkuDsgJ3SW/mB0UvHUfkrfA=;
 b=qF9k9oqt64K7Y7HmscFIZ3YX2U0UrZyVBaMMYL+H9X1tQT6KSFBQSLH23G/qtXitYS
 OQ2bWHqktucXS5+CCN3rn4/beEkOoCdw+4sWWEBrwNryb2JTVTrV3yRzinZfRj9NHzVc
 hK4Rr3viYloGqQ/dO3yDti+V+5M2Lids/4/6CtrnI/8HNwD47xO17CUdTfjktsFhKBOj
 m+BdS3UscFu6O+fQL8VkPurWFusgVKpIezi1yqmS+k5gID1AoCBZ+31uqkdInQzQ4AoS
 HjUzkfIyZCf2aYXX5PvAiFTfMyY32L5MrzhZOqMVeHEkLPY+UA0LQDTg0wLBVMPNXF+e
 MGrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=4CPsG5NQB1SZkSubcvaRzkuDsgJ3SW/mB0UvHUfkrfA=;
 b=SmqxiYFEWTzdk8QsK/oteeybw4gZBnCtw31QxIkgUz+H1QFJzguGoMnz1vAyrnbhX8
 paH2kW0JB7t7O7XCTO0vLeJLYqQiAfHg/SC1E86Zg6DxiyNH7WseyzXuOojKZW7XGXq7
 1FyEF0oRcoEqajy8KGIIOgcdbYWu/mOaoUuM/jk8uPVteig8oQ4x4C3E6Xvu5qnOXwhM
 6Ouhbp3EKoRj86UgrVnQQab8V3VLgrZaDWczFHojQGRsh78r9iwXFX8CvYbq7Y/K0qTe
 xAG9W8yJKkAJfNyJNxjhrdLTCBl6p4slLcRrn4ozI3+FY7T0RnJpogf/gO+UJH4WCeRf
 8dRQ==
X-Gm-Message-State: AOAM530ehjHVKriE7V9QmjNAlnHxUWdjEaVjSoY+LzhWBwcOlGyviwSq
 8/PVFhUvEt6YecnqARYS5qGcnDC1NvODcHlbBsqd4qv775w=
X-Google-Smtp-Source: ABdhPJxnyNNlNGlf5qSIshqJyJ3pB6IbtfRETPbwHZmuTvmz6X480aWHb0NCcMgftByTTm84Af/9lFTZkAsj8cIBQGU=
X-Received: by 2002:a05:6000:8b:: with SMTP id
 m11mr5501459wrx.224.1619192367353; 
 Fri, 23 Apr 2021 08:39:27 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+E_e=0rjq5_XazV_qH2h=uQrpTLbMRe2K7jVterSAr05w@mail.gmail.com>
 <CAD5xwhjUP+=TWtJWSjwFLit7finoVOwpF8bMydOxxVeV8M9oOA@mail.gmail.com>
In-Reply-To: <CAD5xwhjUP+=TWtJWSjwFLit7finoVOwpF8bMydOxxVeV8M9oOA@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Fri, 23 Apr 2021 11:39:15 -0400
Message-ID: <CALZpt+FOuN0HN607ri=nmoyPHaixVR810Qqo9xc41Q_Rq4h9mQ@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>
Content-Type: multipart/alternative; boundary="000000000000e1102005c0a599b9"
X-Mailman-Approved-At: Fri, 23 Apr 2021 15:51:18 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 "lightning-dev\\\\@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] L2s Onchain Support IRC Workshop
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, 23 Apr 2021 15:39:31 -0000

--000000000000e1102005c0a599b9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jeremy,

Yes dates are floating for now. After Bitcoin 2021, sounds a good idea.

Awesome, I'll be really interested to review again an improved version of
sponsorship. And I'll try to sketch out the sighash_no-input fee-bumping
idea which was floating around last year during pinnings discussions. Yet
another set of trade-offs :)

Le ven. 23 avr. 2021 =C3=A0 11:25, Jeremy <jlrubin@mit.edu> a =C3=A9crit :

> I'd be excited to join. Recommend bumping the date  to mid June, if that'=
s
> ok, as many Americans will be at Bitcoin 2021.
>
> I was thinking about reviving the sponsors proposal with a 100 block lock
> on spending a sponsoring tx which would hopefully make less controversial=
,
> this would be a great place to discuss those tradeoffs.
>
> On Fri, Apr 23, 2021, 8:17 AM Antoine Riard <antoine.riard@gmail.com>
> wrote:
>
>> Hi,
>>
>> During the lastest years, tx-relay and mempool acceptances rules of the
>> base layer have been sources of major security and operational concerns =
for
>> Lightning and other Bitcoin second-layers [0]. I think those areas requi=
re
>> significant improvements to ease design and deployment of higher Bitcoin
>> layers and I believe this opinion is shared among the L2 dev community. =
In
>> order to make advancements, it has been discussed a few times in the las=
t
>> months to organize in-person workshops to discuss those issues with the
>> presence of both L1/L2 devs to make exchange fruitful.
>>
>> Unfortunately, I don't think we'll be able to organize such in-person
>> workshops this year (because you know travel is hard those days...) As a
>> substitution, I'm proposing a series of one or more irc meetings. That
>> said, this substitution has the happy benefit to gather far more folks
>> interested by those issues that you can fit in a room.
>>
>> # Scope
>>
>> I would like to propose the following 4 items as topics of discussion.
>>
>> 1) Package relay design or another generic L2 fee-bumping primitive like
>> sponsorship [0]. IMHO, this primitive should at least solve mempools spi=
kes
>> making obsolete propagation of transactions with pre-signed feerate, sol=
ve
>> pinning attacks compromising Lightning/multi-party contract protocol
>> safety, offer an usable and stable API to L2 software stack, stay
>> compatible with miner and full-node operators incentives and obviously
>> minimize CPU/memory DoS vectors.
>>
>> 2) Deprecation of opt-in RBF toward full-rbf. Opt-in RBF makes it trivia=
l
>> for an attacker to partition network mempools in divergent subsets and f=
rom
>> then launch advanced security or privacy attacks against a Lightning nod=
e.
>> Note, it might also be a concern for bandwidth bleeding attacks against =
L1
>> nodes.
>>
>> 3) Guidelines about coordinated cross-layers security disclosures.
>> Mitigating a security issue around tx-relay or the mempool in Core might
>> have harmful implications for downstream projects. Ideally, L2 projects
>> maintainers should be ready to upgrade their protocols in emergency in
>> coordination with base layers developers.
>>
>> 4) Guidelines about L2 protocols onchain security design. Currently
>> deployed like Lightning are making a bunch of assumptions on tx-relay an=
d
>> mempool acceptances rules. Those rules are non-normative, non-reliable a=
nd
>> lack documentation. Further, they're devoid of tooling to enforce them a=
t
>> runtime [2]. IMHO, it could be preferable to identify a subset of them o=
n
>> which second-layers protocols can do assumptions without encroaching too
>> much on nodes's policy realm or making the base layer development in tho=
se
>> areas too cumbersome.
>>
>> I'm aware that some folks are interested in other topics such as
>> extension of Core's mempools package limits or better pricing of RBF
>> replacement. So l propose a 2-week concertation period to submit other
>> topics related to tx-relay or mempools improvements towards L2s before t=
o
>> propose a finalized scope and agenda.
>>
>> # Goals
>>
>> 1) Reaching technical consensus.
>> 2) Reaching technical consensus, before seeking community consensus as i=
t
>> likely has ecosystem-wide implications.
>> 3) Establishing a security incident response policy which can be applied
>> by dev teams in the future.
>> 4) Establishing a philosophy design and associated documentations (BIPs,
>> best practices, ...)
>>
>> # Timeline
>>
>> 2021-04-23: Start of concertation period
>> 2021-05-07: End of concertation period
>> 2021-05-10: Proposition of workshop agenda and schedule
>> late 2021-05/2021-06: IRC meetings
>>
>> As the problem space is savagely wide, I've started a collection of
>> documents to assist this workshop : https://github.com/ariard/L2-zoology
>> Still wip, but I'll have them in a good shape at agenda publication, wit=
h
>> reading suggestions and open questions to structure discussions.
>> Also working on transaction pinning and mempool partitions attacks
>> simulations.
>>
>> If L2s security/p2p/mempool is your jam, feel free to get involved :)
>>
>> Cheers,
>> Antoine
>>
>> [0] For e.g see optech section on transaction pinning attacks :
>> https://bitcoinops.org/en/topics/transaction-pinning/
>> [1]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/0=
18168.html
>> [2] Lack of reference tooling make it easier to have bug slip in like
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/0=
02858.html
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>

--000000000000e1102005c0a599b9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Hi Jeremy,<br><br></div>Yes dates are floating f=
or now. After Bitcoin 2021, sounds a good idea.<br><br></div>Awesome, I&#39=
;ll be really interested to review again an improved version of sponsorship=
. And I&#39;ll try to sketch out the sighash_no-input fee-bumping idea whic=
h was floating around last year during pinnings discussions. Yet another se=
t of trade-offs :)<br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
 class=3D"gmail_attr">Le=C2=A0ven. 23 avr. 2021 =C3=A0=C2=A011:25, Jeremy &=
lt;<a href=3D"mailto:jlrubin@mit.edu">jlrubin@mit.edu</a>&gt; a =C3=A9crit=
=C2=A0:<br></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"><div dir=
=3D"auto"><div>I&#39;d be excited to join. Recommend bumping the date=C2=A0=
 to mid June, if that&#39;s ok, as many Americans will be at Bitcoin 2021.<=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">I was thinking about rev=
iving the sponsors proposal with a 100 block lock on spending a sponsoring =
tx which would hopefully make less controversial, this would be a great pla=
ce to discuss those tradeoffs.=C2=A0<br><br><div class=3D"gmail_quote" dir=
=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Apr 23, 2021, 8:17 =
AM Antoine Riard &lt;<a href=3D"mailto:antoine.riard@gmail.com" target=3D"_=
blank">antoine.riard@gmail.com</a>&gt; 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"><div dir=3D"ltr">Hi,<br><br>During the lastes=
t years, tx-relay and mempool acceptances rules of the base layer have been=
 sources of major security and operational concerns for Lightning and other=
 Bitcoin second-layers [0]. I think those areas require significant improve=
ments to ease design and deployment of higher Bitcoin layers and I believe =
this opinion is shared among the L2 dev community. In order to make advance=
ments, it has been discussed a few times in the last months to organize in-=
person workshops to discuss those issues with the presence of both L1/L2 de=
vs to make exchange fruitful.<br><br>Unfortunately, I don&#39;t think we&#3=
9;ll be able to organize such in-person workshops this year (because you kn=
ow travel is hard those days...) As a substitution, I&#39;m proposing a ser=
ies of one or more irc meetings. That said, this substitution has the happy=
 benefit to gather far more folks interested by those issues that you can f=
it in a room.<br><br># Scope<br><br>I would like to propose the following 4=
 items as topics of discussion.<br><br>1) Package relay design or another g=
eneric L2 fee-bumping primitive like sponsorship [0]. IMHO, this primitive =
should at least solve mempools spikes making obsolete propagation of transa=
ctions with pre-signed feerate, solve pinning attacks compromising Lightnin=
g/multi-party contract protocol safety, offer an usable and stable API to L=
2 software stack, stay compatible with miner and full-node operators incent=
ives and obviously minimize CPU/memory DoS vectors.<br><br>2) Deprecation o=
f opt-in RBF toward full-rbf. Opt-in RBF makes it trivial for an attacker t=
o partition network mempools in divergent subsets and from then launch adva=
nced security or privacy attacks against a Lightning node. Note, it might a=
lso be a concern for bandwidth bleeding attacks against L1 nodes.<br><br>3)=
 Guidelines about coordinated cross-layers security disclosures. Mitigating=
 a security issue around tx-relay or the mempool in Core might have harmful=
 implications for downstream projects. Ideally, L2 projects maintainers sho=
uld be ready to upgrade their protocols in emergency in coordination with b=
ase layers developers.<br><br>4) Guidelines about L2 protocols onchain secu=
rity design. Currently deployed like Lightning are making a bunch of assump=
tions on tx-relay and mempool acceptances rules. Those rules are non-normat=
ive, non-reliable and lack documentation. Further, they&#39;re devoid of to=
oling to enforce them at runtime [2]. IMHO, it could be preferable to ident=
ify a subset of them on which second-layers protocols can do assumptions wi=
thout encroaching too much on nodes&#39;s policy realm or making the base l=
ayer development in those areas too cumbersome.<br><br>I&#39;m aware that s=
ome folks are interested in other topics such as extension of Core&#39;s me=
mpools package limits or better pricing of RBF replacement. So l propose a =
2-week concertation period to submit other topics related to tx-relay or me=
mpools improvements towards L2s before to propose a finalized scope and age=
nda.<br><br># Goals<br><br>1) Reaching technical consensus.<br>2) Reaching =
technical consensus, before seeking community consensus as it likely has ec=
osystem-wide implications.<br>3) Establishing a security incident response =
policy which can be applied by dev teams in the future.<br>4) Establishing =
a philosophy design and associated documentations (BIPs, best practices, ..=
.)<br><br># Timeline<br><br>2021-04-23: Start of concertation period<br>202=
1-05-07: End of concertation period<br>2021-05-10: Proposition of workshop =
agenda and schedule<br>late 2021-05/2021-06: IRC meetings<br><br>As the pro=
blem space is savagely wide, I&#39;ve started a collection of documents to =
assist this workshop : <a href=3D"https://github.com/ariard/L2-zoology" rel=
=3D"noreferrer" target=3D"_blank">https://github.com/ariard/L2-zoology</a><=
br>Still wip, but I&#39;ll have them in a good shape at agenda publication,=
 with reading suggestions and open questions to structure discussions.<br>A=
lso working on transaction pinning and mempool partitions attacks simulatio=
ns.<br><br>If L2s security/p2p/mempool is your jam, feel free to get involv=
ed :)<br><br>Cheers,<br>Antoine<br><br>[0] For e.g see optech section on tr=
ansaction pinning attacks : <a href=3D"https://bitcoinops.org/en/topics/tra=
nsaction-pinning/" rel=3D"noreferrer" target=3D"_blank">https://bitcoinops.=
org/en/topics/transaction-pinning/</a><br>[1] <a href=3D"https://lists.linu=
xfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html" rel=3D"no=
referrer" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/bit=
coin-dev/2020-September/018168.html</a><br>[2] Lack of reference tooling ma=
ke it easier to have bug slip in like <a href=3D"https://lists.linuxfoundat=
ion.org/pipermail/lightning-dev/2020-October/002858.html" rel=3D"noreferrer=
" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/lightning-d=
ev/2020-October/002858.html</a><br></div>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href=3D"mailto:Lightning-dev@lists.linuxfoundation.org" rel=3D"noreferre=
r" target=3D"_blank">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev=
" rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfounda=
tion.org/mailman/listinfo/lightning-dev</a><br>
</blockquote></div></div></div>
</blockquote></div>

--000000000000e1102005c0a599b9--