path: root/a4/b499328d41baa1764589889c002a084b1e4a92

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 7DB02C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 27 Apr 2021 14:54:27 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 5702C4015E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 27 Apr 2021 14:54:27 +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 Dr_UWu9gX2cZ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 27 Apr 2021 14:54:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com
 [IPv6:2a00:1450:4864:20::32d])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 6B5B840122
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 27 Apr 2021 14:54:25 +0000 (UTC)
Received: by mail-wm1-x32d.google.com with SMTP id
 n3-20020a05600c4f83b02901425630b2c2so1182140wmq.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 27 Apr 2021 07:54:25 -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=1jU1wlqTPRxQnHxYgBBppHWTQl1hVOQycA3ZUjLXuhA=;
 b=ajKtKXCBTf0AhYOg64OnlZC5Z7ZPxjU92Drpwo6OiEKtJ1+mmC01X/q+A7W2/bBSP1
 NioUboi9MFwEdE2+4WiNHWDFUyqr5F6cF2z5qX9WPbTnY/J6go6Mwx9RnRdQplnhOGa0
 BwvkkbOGNE2iuf5uozaABU5ALlBamnKeRrz8SdrY8MLmbWytwhnPgo5bgELD6orPg9BW
 tH6mqsfOPdO69mEM8xpQ8WiDksoQJ1AVY18aewcyOp589NHL1xOzwb4X1WczcJ5+sgAA
 i1rESUaLpVZwuXVpQx232RdgwpBEb5tulkrUKN5T3nn2Sy+D4jA1U4ReFADc0Xo2eJR0
 7R2w==
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=1jU1wlqTPRxQnHxYgBBppHWTQl1hVOQycA3ZUjLXuhA=;
 b=U/NVGdYJxD19gcNfk4Ff9NLfBDFcFEA816e5QahHH3OIKd9EH7UoLdVYFOow2w23No
 B7fuHNMJSUGlK6/AxR8ZJdLdWxv9X+J7BH1YiQCLdROlIQjFVedFzyNZ80s214opezw/
 a0SpYEXhynllU4M4d7j8sokvh8rUgF9wUy90MBUNrudLDRVHUHOOfkdiu4by+ikNnIUW
 TbTx+2FdNsXG3CLq/ltCqQfFawmC7+GGQaBR/2BJoQBwVDhzIJtCFa1AfcfBQwaagj5z
 +QTKl4mQPTsc7Cc/Geqa2kprH5kfjGFYvaPqyQ7xaPV+9MxFYRogANzsLCsDX4Il3xnX
 LNMQ==
X-Gm-Message-State: AOAM532aGWT7BxxqYbeSnXEI3XjYKGjSh8wlKERfKWNmxTsHtuQrYBDS
 nuFqDk3gQm1gxmNYwktmNr0667+x+5j98B6P9SU=
X-Google-Smtp-Source: ABdhPJyP6+rhz4pkoFvD3kUNUHm1DeU9xd3aAU38QR/TX5AK7qaKIrO+HjEQd02dMeOVhsNP585ynUvSkSJY4q5ZQPc=
X-Received: by 2002:a7b:c012:: with SMTP id c18mr4893554wmb.94.1619535263530; 
 Tue, 27 Apr 2021 07:54:23 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+E_e=0rjq5_XazV_qH2h=uQrpTLbMRe2K7jVterSAr05w@mail.gmail.com>
 <CAFXO6=J-3kF4nOqrHLRzN2t+=iCrCDTJh9nD3tY45ihZOAZ8ug@mail.gmail.com>
In-Reply-To: <CAFXO6=J-3kF4nOqrHLRzN2t+=iCrCDTJh9nD3tY45ihZOAZ8ug@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Tue, 27 Apr 2021 10:54:12 -0400
Message-ID: <CALZpt+FxikOrmz8Dt596QdMWzWYMFMwzOCOcfoiT9evaC9PimA@mail.gmail.com>
To: Gloria Zhao <gloriajzhao@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000001582cf05c0f570bc"
X-Mailman-Approved-At: Tue, 27 Apr 2021 15:50:43 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-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: Tue, 27 Apr 2021 14:54:27 -0000

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

Hi Gloria,

Thanks for your interest in joining.

> A small note - I believe package relay and sponsorship (or other
> fee-bumping primitive) should be separate discussions.

Here my thinking on the question, ideally we would have one generic
fee-bumping primitive suiting any contracting protocol or Bitcoin
applications onchain requirements. In the future, that
would avoid the mempool and transaction relay rules being lobbied by any L2
community to add support for their specific onchain desiratas. Of course,
L2 communities are always able to deploy their own overlay infrastructure
but at the price of losing the censorship-resistance guarantees of the
current base layer p2p network.

Further, we already have concerns of competing onchain requirements between
Bitcoin merchants and Lightning protocol dev about RBF. IMO, full-rbf will
harden LN against some state-of-art attacks but at same time make it easier
to double-spend merchants.

How do we arbiter between categories of users requirements ? I don't know,
best is to have an open discussion about it ?

Back to package relay, I also think that's the easiest candidate to deploy
because it doesn't rely on any consensus change. What I'm concerned about
is one package relay design working fine for the vast majority of cases but
irrelevant or broken to address adversarial settings. Even more, it might
work fine for LN but not at all for more fancy protocols still on the
whiteboard like op_ctv-style
congestion tree.

Though in many cases it is better to adopt an almost complete solution now,
rather than to wait until a perfect solution can be found. Likely, the best
we can do is keep design modular, version everything and be ready to deploy
multiple versions of package relay in the coming years as our knowledge in
those areas improves.

> Re: L2-zoology... In general, for the purpose of creating a stable API /
> set of assumptions between layers, I'd like to be as concrete as possible=
.
> Speaking for myself, if I'm TDDing for a specific L2 attack, I need test
> vectors. A simple description of mempool contents + p2p messages sent is
> fine, but pubkeys + transaction hex would be appreciated because we don't
> (and probably shouldn't, for the purpose of maintainability) have a lot o=
f
> tooling to build L2 transactions in Bitcoin Core. In the other direction,
> it's hard to make any guarantees given the complexity of mempool policy,
> but perhaps it could be helpful to expose a configurable RPC (e.g. #21413
> <https://github.com/bitcoin/bitcoin/pull/21413>) to test a range of
> scenarios?

We're aligned here, I'd like to be as concrete as possible too. As a L1/L2
dev, I've just a bunch of questions and don't pretend to have clear answers
for each of them yet nor I think those answers will be the best ones. So
maybe the first step is just tracking and explaining problems better,
hopefully avoiding to waste too much engineering hours on could-be-enhanced
solutions ?

Actively working on better demonstrations and will share them soon. That
said, anyone interested in improving their own understanding in those areas
are free to make their own investigations :)

Cheers,
Antoine

Le lun. 26 avr. 2021 =C3=A0 19:06, Gloria Zhao <gloriajzhao@gmail.com> a =
=C3=A9crit :

> Hi Antoine,
>
> Thanks for initiating this! I'm interested in joining. Since I mostly liv=
e
> in L1, my primary goal is to understand what simplest version of package
> relay would be sufficient to support transaction relay assumptions made b=
y
> L2 applications. For example, if a parent + child package covers the vast
> majority of cases and a package limit of 2 is considered acceptable, that
> could simplify things quite a bit.
>
> A small note - I believe package relay and sponsorship (or other
> fee-bumping primitive) should be separate discussions.
>
> Re: L2-zoology... In general, for the purpose of creating a stable API /
> set of assumptions between layers, I'd like to be as concrete as possible=
.
> Speaking for myself, if I'm TDDing for a specific L2 attack, I need test
> vectors. A simple description of mempool contents + p2p messages sent is
> fine, but pubkeys + transaction hex would be appreciated because we don't
> (and probably shouldn't, for the purpose of maintainability) have a lot o=
f
> tooling to build L2 transactions in Bitcoin Core. In the other direction,
> it's hard to make any guarantees given the complexity of mempool policy,
> but perhaps it could be helpful to expose a configurable RPC (e.g. #21413
> <https://github.com/bitcoin/bitcoin/pull/21413>) to test a range of
> scenarios?
>
> Anyway, looking forward to discussions :)
>
> Best,
> Gloria
>
> On Fri, Apr 23, 2021 at 8:51 AM Antoine Riard via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> 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
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

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

<div dir=3D"ltr">Hi Gloria,<br><br>Thanks for your interest in joining.<br>=
<br>&gt; A small note - I believe package relay and sponsorship (or other<b=
r>&gt; fee-bumping primitive) should be separate discussions.<br><br>Here m=
y thinking on the question, ideally we would have one generic fee-bumping p=
rimitive suiting any contracting protocol or Bitcoin applications onchain r=
equirements. In the future, that<br>would avoid the mempool and transaction=
 relay rules being lobbied by any L2 community to add support for their spe=
cific onchain desiratas. Of course, L2 communities are always able to deplo=
y their own overlay infrastructure but at the price of losing the censorshi=
p-resistance guarantees of the current base layer p2p network.<br><br>Furth=
er, we already have concerns of competing onchain requirements between Bitc=
oin merchants and Lightning protocol dev about RBF. IMO, full-rbf will hard=
en LN against some state-of-art attacks but at same time make it easier to =
double-spend merchants.<br><br>How do we arbiter between categories of user=
s requirements ? I don&#39;t know, best is to have an open discussion about=
 it ?<br><br>Back to package relay, I also think that&#39;s the easiest can=
didate to deploy because it doesn&#39;t rely on any consensus change. What =
I&#39;m concerned about is one package relay design working fine for the va=
st majority of cases but irrelevant or broken to address adversarial settin=
gs. Even more, it might work fine for LN but not at all for more fancy prot=
ocols still on the whiteboard like op_ctv-style<br>congestion tree.<br><br>=
Though in many cases it is better to adopt an almost complete solution now,=
 rather than to wait until a perfect solution can be found. Likely, the bes=
t we can do is keep design modular, version everything and be ready to depl=
oy multiple versions of package relay in the coming years as our knowledge =
in those areas improves.<br><br>&gt; Re: L2-zoology... In general, for the =
purpose of creating a stable API /<br>&gt; set of assumptions between layer=
s, I&#39;d like to be as concrete as possible.<br>&gt; Speaking for myself,=
 if I&#39;m TDDing for a specific L2 attack, I need test<br>&gt; vectors. A=
 simple description of mempool contents + p2p messages sent is<br>&gt; fine=
, but pubkeys + transaction hex would be appreciated because we don&#39;t<b=
r>&gt; (and probably shouldn&#39;t, for the purpose of maintainability) hav=
e a lot of<br>&gt; tooling to build L2 transactions in Bitcoin Core. In the=
 other direction,<br>&gt; it&#39;s hard to make any guarantees given the co=
mplexity of mempool policy,<br>&gt; but perhaps it could be helpful to expo=
se a configurable RPC (e.g. #21413<br>&gt; &lt;<a href=3D"https://github.co=
m/bitcoin/bitcoin/pull/21413">https://github.com/bitcoin/bitcoin/pull/21413=
</a>&gt;) to test a range of<br>&gt; scenarios?<br><br>We&#39;re aligned he=
re, I&#39;d like to be as concrete as possible too. As a L1/L2 dev, I&#39;v=
e just a bunch of questions and don&#39;t pretend to have clear answers for=
 each of them yet nor I think those answers will be the best ones. So maybe=
 the first step is just tracking and explaining problems better, hopefully =
avoiding to waste too much engineering hours on could-be-enhanced solutions=
 ?<br><br>Actively working on better demonstrations and will share them soo=
n. That said, anyone interested in improving their own understanding in tho=
se areas are free to make their own investigations :)<br><br>Cheers,<br>Ant=
oine</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_at=
tr">Le=C2=A0lun. 26 avr. 2021 =C3=A0=C2=A019:06, Gloria Zhao &lt;<a href=3D=
"mailto:gloriajzhao@gmail.com">gloriajzhao@gmail.com</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"ltr"><div dir=3D"ltr"><div>Hi Antoine,</div><div><br></div><div>Thanks =
for initiating this! I&#39;m interested in joining. Since I mostly live in =
L1, my primary goal is to understand what simplest version of package relay=
 would be sufficient to support transaction relay assumptions made by L2 ap=
plications. For example, if a parent + child package covers the vast majori=
ty of cases and a package limit of 2 is considered acceptable, that could s=
implify things quite a bit.</div><div><br></div><div>A small note - I belie=
ve package relay and sponsorship (or other fee-bumping primitive) should be=
 separate discussions.</div><div><br></div><div>Re: L2-zoology... In genera=
l, for the purpose of creating a stable API / set of assumptions between la=
yers, I&#39;d like to be as concrete as possible. Speaking for myself, if I=
&#39;m TDDing for a specific L2 attack, I need test vectors. A simple descr=
iption of mempool contents + p2p messages sent is fine, but pubkeys + trans=
action hex would be appreciated because we don&#39;t (and probably shouldn&=
#39;t, for the purpose of maintainability) have a lot of tooling to build L=
2 transactions in Bitcoin Core.  In the other direction, it&#39;s hard to m=
ake any guarantees given the complexity of mempool policy, but perhaps it c=
ould be helpful to expose a configurable RPC (e.g. #<a href=3D"https://gith=
ub.com/bitcoin/bitcoin/pull/21413" target=3D"_blank">21413</a>) to test a r=
ange of scenarios?</div><div><br></div><div>Anyway, looking forward to disc=
ussions :)<br></div><div><br></div><div>Best,</div><div>Gloria<br></div></d=
iv><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On =
Fri, Apr 23, 2021 at 8:51 AM Antoine Riard via bitcoin-dev &lt;<a href=3D"m=
ailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@=
lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"ltr">Hi,<br><br>During the lastest yea=
rs, tx-relay and mempool acceptances rules of the base layer have been sour=
ces of major security and operational concerns for Lightning and other Bitc=
oin 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-perso=
n workshops to discuss those 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 tr=
avel is hard those days...) As a substitution, I&#39;m proposing a series o=
f one or more irc meetings. That said, this substitution has the happy bene=
fit to gather far more folks interested by those issues that you can fit in=
 a room.<br><br># Scope<br><br>I would like to propose the following 4 item=
s as topics of discussion.<br><br>1) Package relay design or another generi=
c L2 fee-bumping primitive like sponsorship [0]. IMHO, this primitive shoul=
d at least solve mempools spikes making obsolete propagation of transaction=
s with pre-signed feerate, solve pinning attacks compromising Lightning/mul=
ti-party contract protocol safety, offer an usable and stable API to L2 sof=
tware stack, stay compatible with miner and full-node operators incentives =
and obviously minimize CPU/memory DoS vectors.<br><br>2) Deprecation of opt=
-in RBF toward full-rbf. Opt-in RBF makes it trivial for an attacker to par=
tition network mempools in divergent subsets and from then launch advanced =
security or privacy attacks against a Lightning node. Note, it might also b=
e a concern for bandwidth bleeding attacks against L1 nodes.<br><br>3) Guid=
elines about coordinated cross-layers security disclosures. Mitigating a se=
curity issue around tx-relay or the mempool in Core might have harmful impl=
ications for downstream projects. Ideally, L2 projects maintainers should b=
e ready to upgrade their protocols in emergency in coordination with base l=
ayers developers.<br><br>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&#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 protocols can do assumptions without=
 encroaching too much on nodes&#39;s policy realm or making the base layer =
development in those areas too cumbersome.<br><br>I&#39;m aware that some f=
olks are interested in other topics such as extension of Core&#39;s mempool=
s package limits or better pricing of RBF replacement. So l propose a 2-wee=
k concertation period to submit other topics related to tx-relay or mempool=
s improvements towards L2s before to propose a finalized scope and agenda.<=
br><br># Goals<br><br>1) Reaching technical consensus.<br>2) Reaching techn=
ical consensus, before seeking community consensus as it likely has ecosyst=
em-wide implications.<br>3) Establishing a security incident response polic=
y which can be applied by dev teams in the future.<br>4) Establishing a phi=
losophy design and associated documentations (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 agend=
a and schedule<br>late 2021-05/2021-06: IRC meetings<br><br>As the problem =
space is savagely wide, I&#39;ve started a collection of documents to assis=
t this workshop : <a href=3D"https://github.com/ariard/L2-zoology" target=
=3D"_blank">https://github.com/ariard/L2-zoology</a><br>Still wip, but I&#3=
9;ll have them in a good shape at agenda publication, with reading suggesti=
ons and open questions to structure discussions.<br>Also working on transac=
tion pinning and mempool partitions attacks simulations.<br><br>If L2s secu=
rity/p2p/mempool is your jam, feel free to get involved :)<br><br>Cheers,<b=
r>Antoine<br><br>[0] For e.g see optech section on transaction pinning atta=
cks : <a href=3D"https://bitcoinops.org/en/topics/transaction-pinning/" tar=
get=3D"_blank">https://bitcoinops.org/en/topics/transaction-pinning/</a><br=
>[1] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/202=
0-September/018168.html" target=3D"_blank">https://lists.linuxfoundation.or=
g/pipermail/bitcoin-dev/2020-September/018168.html</a><br>[2] Lack of refer=
ence tooling make it easier to have bug slip in like <a href=3D"https://lis=
ts.linuxfoundation.org/pipermail/lightning-dev/2020-October/002858.html" ta=
rget=3D"_blank">https://lists.linuxfoundation.org/pipermail/lightning-dev/2=
020-October/002858.html</a><br></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>
</blockquote></div>

--0000000000001582cf05c0f570bc--