path: root/1b/f477f48928d0dde481ab1c029b1cf8a4f7aa57

Return-Path: <bastien.teinturier@acinq.fr>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A5671C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 23 Apr 2021 16:17:51 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 87BDD40640
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 23 Apr 2021 16:17:51 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
 autolearn=unavailable autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=acinq-fr.20150623.gappssmtp.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 3DlHitx0Fplb
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 23 Apr 2021 16:17:49 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com
 [IPv6:2607:f8b0:4864:20::b2e])
 by smtp2.osuosl.org (Postfix) with ESMTPS id DD5D74064A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 23 Apr 2021 16:17:48 +0000 (UTC)
Received: by mail-yb1-xb2e.google.com with SMTP id p126so2607867yba.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 23 Apr 2021 09:17:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=acinq-fr.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=lXs6Vn9S5+nhLVXpm3BgdNss3+tXrYwJAJ6X+kSyIG4=;
 b=Gnw1IHgCf0j+puq/1SQwN0Pu+L+8RDRdPPpE5qnSbbOVsEVrv0BSdkX0X+VzptG3jE
 IBU48t5QvGzGLHAUKKnA+fpqPC5Zjl3MmLhsbWlDb0ivEdXbuPEishujbzbBy0TnDtSp
 CNFyszZsrgiTKmnDQmbWVhVYawX0f4dRmhJ2rCF5EBSkOrYBigXL5pwis5yDCMbB8XW5
 xuHByO4ZFtVTYg4TCV+IEDvgr/YYlMdKpBw8CsmsHoEhDVG89RmqrnSI++u3/NuVvCNn
 96k8jl+Iinq9zlCgwL2ob6pDaeIxWNiIF2rGBqeNlrHcueU8b9Ovve0hMG7Q6g6cRrqw
 g+bA==
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=lXs6Vn9S5+nhLVXpm3BgdNss3+tXrYwJAJ6X+kSyIG4=;
 b=HkVeGbV/Td5ZTYcI+obbh5Fbkap4GrVczPplqJeovBoz8uCzkDmCJ2CPca/F7HJI9o
 uOUUR14PYiVkwYgnuh5iPT3g+JE3Mpp90KUNXNy1BNdozXpbpbmE1vOQdjivUuwVWI10
 42AFBsrgtgKCPvZrZu6zG7Bf+ieT+gMQJ49VhJ+/YLeftkO8+3GV1citSqD8squlQ0iv
 l0PBMpt607SaWJVnSpqggTJEKuePe3/1hiKFmxFlV9sCPaoXSfZtOGO3hSFNnnH77VOj
 qUtA9DfjDI5RFzcMowtcmaMmLg0c2uWMRYfzAfI8TG0IaGqumJa2f678HDJM4tdPodcX
 Dz/w==
X-Gm-Message-State: AOAM530bjWcrPuHniEqz6bw6hLuHn1Q9FfA+PJPA97g8hvnF6r/bLCLl
 FcWJNwB5uQF/LCwdYZyw3m991lc5+XX4M4fXLtfsCA==
X-Google-Smtp-Source: ABdhPJx7cQrYD/EnZKZJSFX7Sckds5L5RgKFPsyNWKpg0aBpECjnS1rslry8mZNgxZC+uPA1q/1zSmw/RXof7gn5O9U=
X-Received: by 2002:a25:316:: with SMTP id 22mr7006534ybd.523.1619194667650;
 Fri, 23 Apr 2021 09:17:47 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+E_e=0rjq5_XazV_qH2h=uQrpTLbMRe2K7jVterSAr05w@mail.gmail.com>
 <CAD5xwhjUP+=TWtJWSjwFLit7finoVOwpF8bMydOxxVeV8M9oOA@mail.gmail.com>
 <CALZpt+FOuN0HN607ri=nmoyPHaixVR810Qqo9xc41Q_Rq4h9mQ@mail.gmail.com>
In-Reply-To: <CALZpt+FOuN0HN607ri=nmoyPHaixVR810Qqo9xc41Q_Rq4h9mQ@mail.gmail.com>
From: Bastien TEINTURIER <bastien@acinq.fr>
Date: Fri, 23 Apr 2021 18:17:36 +0200
Message-ID: <CACdvm3Mnf7Xuts9z+WiyyK=Pm2iWy_VT9bGSAUsATtxjGUS4uw@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000fce50605c0a62245"
X-Mailman-Approved-At: Fri, 23 Apr 2021 17:08:03 +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 16:17:51 -0000

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

Great idea, I'll join as well.
Thanks for setting this in motion.

Le ven. 23 avr. 2021 =C3=A0 17:39, Antoine Riard <antoine.riard@gmail.com> =
a
=C3=A9crit :

> 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 loc=
k
>> on spending a sponsoring tx which would hopefully make less controversia=
l,
>> 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 requ=
ire
>>> significant improvements to ease design and deployment of higher Bitcoi=
n
>>> 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 la=
st
>>> 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 lik=
e
>>> sponsorship [0]. IMHO, this primitive should at least solve mempools sp=
ikes
>>> making obsolete propagation of transactions with pre-signed feerate, so=
lve
>>> 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 subs=
ets
>>> 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 migh=
t
>>> 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 a=
nd
>>> 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 to=
o
>>> much on nodes's policy realm or making the base layer development in th=
ose
>>> 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 applie=
d
>>> 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-zoolog=
y
>>> 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
>>>
>> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>

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

<div dir=3D"ltr">Great idea, I&#39;ll join as well.<div>Thanks for setting =
this in motion.</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">Le=C2=A0ven. 23 avr. 2021 =C3=A0=C2=A017:39, Antoine R=
iard &lt;<a href=3D"mailto:antoine.riard@gmail.com">antoine.riard@gmail.com=
</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr"><div><div>Hi Jeremy,<br><br></div>Yes dates a=
re floating for now. After Bitcoin 2021, sounds a good idea.<br><br></div>A=
wesome, I&#39;ll be really interested to review again an improved version o=
f sponsorship. And I&#39;ll try to sketch out the sighash_no-input fee-bump=
ing idea which was floating around last year during pinnings discussions. Y=
et another set of trade-offs :)<br></div><br><div class=3D"gmail_quote"><di=
v 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" target=3D"_blank">jlrubi=
n@mit.edu</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"auto"><div>I&#39;d be excited to join. Re=
commend bumping the date=C2=A0 to mid June, if that&#39;s ok, as many Ameri=
cans will be at Bitcoin 2021.</div><div dir=3D"auto"><br></div><div dir=3D"=
auto">I was thinking about reviving the sponsors proposal with a 100 block =
lock on spending a sponsoring tx which would hopefully make less controvers=
ial, this would be a great place 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.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
>Hi,<br><br>During the lastest years, tx-relay and mempool acceptances rule=
s of the base layer have been sources of major security and operational con=
cerns for Lightning and other Bitcoin second-layers [0]. I think those area=
s require significant improvements to ease design and deployment of higher =
Bitcoin layers and I believe this opinion is shared among the L2 dev commun=
ity. In order to make advancements, it has been discussed a few times in th=
e last months to organize in-person workshops to discuss those issues with =
the presence of both L1/L2 devs to make exchange fruitful.<br><br>Unfortuna=
tely, I don&#39;t think we&#39;ll be able to organize such in-person worksh=
ops this year (because you know travel is hard those days...) As a substitu=
tion, I&#39;m proposing a series of one or more irc meetings. That said, th=
is substitution has the happy benefit to gather far more folks interested b=
y those issues that you can fit in a room.<br><br># Scope<br><br>I would li=
ke to propose the following 4 items as topics of discussion.<br><br>1) Pack=
age relay design or another generic L2 fee-bumping primitive like sponsorsh=
ip [0]. IMHO, this primitive should at least solve mempools spikes making o=
bsolete 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 a=
nd full-node operators incentives and obviously minimize CPU/memory DoS vec=
tors.<br><br>2) Deprecation of opt-in RBF toward full-rbf. Opt-in RBF makes=
 it trivial for an attacker to partition network mempools in divergent subs=
ets and from then launch advanced security or privacy attacks against a Lig=
htning node. Note, it might also be a concern for bandwidth bleeding attack=
s against L1 nodes.<br><br>3) Guidelines about coordinated cross-layers sec=
urity disclosures. Mitigating a security issue around tx-relay or the mempo=
ol in Core might have harmful implications for downstream projects. Ideally=
, L2 projects maintainers should be ready to upgrade their protocols in eme=
rgency in coordination with base layers developers.<br><br>4) Guidelines ab=
out L2 protocols onchain security design. Currently deployed like Lightning=
 are making a bunch of assumptions on tx-relay and mempool acceptances rule=
s. Those rules are non-normative, non-reliable and lack documentation. Furt=
her, they&#39;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 pr=
otocols can do assumptions without encroaching too much on nodes&#39;s poli=
cy realm or making the base layer development in those areas too cumbersome=
.<br><br>I&#39;m aware that some folks are interested in other topics such =
as extension of Core&#39;s mempools package limits or better pricing of RBF=
 replacement. So l propose a 2-week concertation period to submit other top=
ics related to tx-relay or mempools improvements towards L2s before to prop=
ose a finalized scope and agenda.<br><br># Goals<br><br>1) Reaching technic=
al consensus.<br>2) Reaching technical consensus, before seeking 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 th=
e future.<br>4) Establishing a philosophy design and associated documentati=
ons (BIPs, best practices, ...)<br><br># Timeline<br><br>2021-04-23: Start =
of concertation period<br>2021-05-07: End of concertation period<br>2021-05=
-10: Proposition of workshop agenda and schedule<br>late 2021-05/2021-06: I=
RC 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://gith=
ub.com/ariard/L2-zoology" rel=3D"noreferrer" target=3D"_blank">https://gith=
ub.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 t=
o structure discussions.<br>Also working on transaction pinning and mempool=
 partitions attacks simulations.<br><br>If L2s security/p2p/mempool is your=
 jam, feel free to get involved :)<br><br>Cheers,<br>Antoine<br><br>[0] For=
 e.g see optech section on transaction pinning attacks : <a href=3D"https:/=
/bitcoinops.org/en/topics/transaction-pinning/" rel=3D"noreferrer" target=
=3D"_blank">https://bitcoinops.org/en/topics/transaction-pinning/</a><br>[1=
] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-S=
eptember/018168.html" rel=3D"noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.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 hre=
f=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October=
/002858.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfound=
ation.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" 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>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href=3D"mailto:Lightning-dev@lists.linuxfoundation.org" target=3D"_blank=
">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev=
" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/ma=
ilman/listinfo/lightning-dev</a><br>
</blockquote></div>

--000000000000fce50605c0a62245--