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"
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
Precedence: list

--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--