MIME-Version: 1.0
References: <CALZpt+E_e=0rjq5_XazV_qH2h=uQrpTLbMRe2K7jVterSAr05w@mail.gmail.com>
In-Reply-To: <CALZpt+E_e=0rjq5_XazV_qH2h=uQrpTLbMRe2K7jVterSAr05w@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Fri, 23 Apr 2021 08:25:19 -0700
Message-ID: <CAD5xwhjUP+=TWtJWSjwFLit7finoVOwpF8bMydOxxVeV8M9oOA@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000013385805c0a56834"
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

--00000000000013385805c0a56834
Content-Type: text/plain; charset="UTF-8"

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 require
> 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 last
> 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 spikes
> making obsolete propagation of transactions with pre-signed feerate, solve
> 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 trivial
> for an attacker to partition network mempools in divergent subsets and from
> then launch advanced security or privacy attacks against a Lightning node.
> 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 and
> mempool acceptances rules. Those rules are non-normative, non-reliable and
> lack documentation. Further, they're devoid of tooling to enforce them at
> runtime [2]. IMHO, it could be preferable to identify a subset of them on
> which second-layers protocols can do assumptions without encroaching too
> much on nodes's policy realm or making the base layer development in those
> 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 to propose a finalized
> scope and agenda.
>
> # Goals
>
> 1) Reaching technical consensus.
> 2) Reaching technical consensus, before seeking community consensus as it
> 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, with
> 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/018168.html
> [2] Lack of reference tooling make it easier to have bug slip in like
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002858.html
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>

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

<div dir=3D"auto"><div>I&#39;d be excited to join. Recommend bumping the da=
te=C2=A0 to mid June, if that&#39;s ok, as many Americans will be at Bitcoi=
n 2021.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I was thinking a=
bout reviving the sponsors proposal with a 100 block lock on spending a spo=
nsoring tx which would hopefully make less controversial, this would be a g=
reat place to discuss those tradeoffs.=C2=A0<br><br><div class=3D"gmail_quo=
te" 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">anto=
ine.riard@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr">Hi,<br><br>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 require significant improvements to ease design and deplo=
yment of higher Bitcoin layers and I believe this opinion is shared among t=
he L2 dev community. In order to make advancements, it has been discussed a=
 few times in the last months to organize in-person workshops to discuss th=
ose issues with the presence of both L1/L2 devs to make exchange fruitful.<=
br><br>Unfortunately, I don&#39;t think we&#39;ll be able to organize such =
in-person workshops this year (because you know travel is hard those days..=
.) As a substitution, I&#39;m proposing a series of one or more irc meeting=
s. That said, this substitution has the happy benefit to gather far more fo=
lks interested by those issues that you can fit in a room.<br><br># Scope<b=
r><br>I would like to propose the following 4 items as topics of discussion=
.<br><br>1) Package relay design or another generic L2 fee-bumping primitiv=
e like sponsorship [0]. IMHO, this primitive should at least solve mempools=
 spikes making obsolete propagation of transactions with pre-signed feerate=
, solve pinning attacks compromising Lightning/multi-party contract protoco=
l safety, offer an usable and stable API to L2 software stack, stay compati=
ble with miner and full-node operators incentives and obviously minimize CP=
U/memory DoS vectors.<br><br>2) Deprecation of opt-in RBF toward full-rbf. =
Opt-in RBF makes it trivial for an attacker to partition network mempools i=
n divergent subsets and from then launch advanced security or privacy attac=
ks against a Lightning node. Note, it might also 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-re=
lay or the mempool in Core might have harmful implications for downstream p=
rojects. Ideally, L2 projects maintainers should be ready to upgrade their =
protocols in emergency in coordination with base layers developers.<br><br>=
4) Guidelines about L2 protocols onchain security design. Currently deploye=
d like Lightning are making a bunch of assumptions on tx-relay and mempool =
acceptances rules. Those rules are non-normative, non-reliable and lack doc=
umentation. Further, they&#39;re devoid of tooling to enforce them at runti=
me [2]. IMHO, it could be preferable to identify a subset of them on which =
second-layers protocols can do assumptions without encroaching too much on =
nodes&#39;s policy realm or making the base layer development in those area=
s too cumbersome.<br><br>I&#39;m aware that some folks are interested in ot=
her topics such as extension of Core&#39;s mempools package limits or bette=
r pricing of RBF replacement. So l propose a 2-week concertation period to =
submit other topics related to tx-relay or mempools improvements towards L2=
s before to propose a finalized scope and agenda.<br><br># Goals<br><br>1) =
Reaching technical consensus.<br>2) Reaching technical consensus, before se=
eking community consensus as it likely has ecosystem-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 associ=
ated documentations (BIPs, best practices, ...)<br><br># Timeline<br><br>20=
21-04-23: Start of concertation period<br>2021-05-07: End of concertation p=
eriod<br>2021-05-10: Proposition of workshop agenda and schedule<br>late 20=
21-05/2021-06: IRC meetings<br><br>As the problem 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" target=3D"_blank" rel=3D"noreferr=
er">https://github.com/ariard/L2-zoology</a><br>Still wip, but I&#39;ll hav=
e them in a good shape at agenda publication, with reading suggestions and =
open questions to structure discussions.<br>Also working on transaction pin=
ning and mempool partitions attacks simulations.<br><br>If L2s security/p2p=
/mempool is your jam, feel free to get involved :)<br><br>Cheers,<br>Antoin=
e<br><br>[0] For e.g see optech section on transaction pinning attacks : <a=
 href=3D"https://bitcoinops.org/en/topics/transaction-pinning/" target=3D"_=
blank" rel=3D"noreferrer">https://bitcoinops.org/en/topics/transaction-pinn=
ing/</a><br>[1] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitc=
oin-dev/2020-September/018168.html" target=3D"_blank" rel=3D"noreferrer">ht=
tps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168=
.html</a><br>[2] Lack of reference tooling make it easier to have bug slip =
in like <a href=3D"https://lists.linuxfoundation.org/pipermail/lightning-de=
v/2020-October/002858.html" target=3D"_blank" rel=3D"noreferrer">https://li=
sts.linuxfoundation.org/pipermail/lightning-dev/2020-October/002858.html</a=
><br></div>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href=3D"mailto:Lightning-dev@lists.linuxfoundation.org" target=3D"_blank=
" rel=3D"noreferrer">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>

--00000000000013385805c0a56834--