path: root/1f/8551ffe0f7f0c4d511353a197ce02e1bcc35ff

Return-Path: <antoine.riard@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1F81AC000B;
 Fri, 23 Apr 2021 15:12:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id F208160667;
 Fri, 23 Apr 2021 15:12:12 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.602
X-Spam-Level: 
X-Spam-Status: No, score=0.602 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, 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_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id ojnMkKhQr5le; Fri, 23 Apr 2021 15:12:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [IPv6:2a00:1450:4864:20::42e])
 by smtp3.osuosl.org (Postfix) with ESMTPS id B24D26064D;
 Fri, 23 Apr 2021 15:12:10 +0000 (UTC)
Received: by mail-wr1-x42e.google.com with SMTP id w4so45027873wrt.5;
 Fri, 23 Apr 2021 08:12:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=tRZsWo2sUR9Auh+8nFRGbhXtKgsKy07q4ukdoB2fj0E=;
 b=Dsb1GE2JauvOEmrGZJsqeebo+DGPt6bbSbHgLq4uMGZ9kNkzIBMXAfU/6jhCeY61OM
 gnML42aQvh4xQcrw1cvP+auAjPEgbIdY7lFwsmlEzQxo9l35lMhzHRb05VlbTHTOpMS+
 ZK6haVcsOAtyUrb9efcWOB1rkETs8PG7vuvICtRu6AqcRD2ESwsA6L5tHBOecvJJvDnC
 wis39g6pihIPsOxOpeW2+j+5HBF3p6ODUCuwun4T43QmptGms9gqiRv6uvF6KEQOjXEM
 28XpD+gqr3FW7ZzRzi/7hMGB47PD+gRNTLfugI5lPttCn9Gl8Qr9+8BVzqF34Zfs2xkY
 IcBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=tRZsWo2sUR9Auh+8nFRGbhXtKgsKy07q4ukdoB2fj0E=;
 b=WmHVX70CCSgJRLe0+GnNr314cc0q1k3zwOySh5DRn7/xFWLe4uFMKBKfm7pbxMjJu8
 uMi1MbhnfQBq2yfROcDMfQLcw/fjI5xmi5GLjXhXJ7JlGmiYW4ogsHWg6dSsn6BMVYN6
 1YHM7ovdFuupAhQ7sPzzrwqe6ufYhdIOSkREygC9Saq2aauwKFAWWPE2r+rxg6sGQLaw
 YqqRVvDBodQlYJmb+fvh/Rh+Diww1pCkrVSB5TquHiVXJBrnyW0caaGWtJ7x6EF24onN
 OZIoWxqgf6uH5fJqWn8YHTQSuaiH/KEfxKQe2RImp0erY+pf925bBddwl8I93/6Top2J
 iqiA==
X-Gm-Message-State: AOAM530CQ5lC018viIfdcI3FeJ0c1sITR5oTyZb0l0iM7YnMix/AAnQx
 xj6xs/Id3L8WMJaaUFqc6brJcYOYrwX7xtITnJ/qugW8vFlffw==
X-Google-Smtp-Source: ABdhPJz5n46rBvUfPlu87yQwlbi6CdgJwA5PfyT6vtfhmPCgRdHZUIdSXAOhnQFD0CGaEmPvumHu2vMAI52vxXxR7cA=
X-Received: by 2002:a05:6000:8b:: with SMTP id
 m11mr5358857wrx.224.1619190728650; 
 Fri, 23 Apr 2021 08:12:08 -0700 (PDT)
MIME-Version: 1.0
From: Antoine Riard <antoine.riard@gmail.com>
Date: Fri, 23 Apr 2021 11:11:56 -0400
Message-ID: <CALZpt+E_e=0rjq5_XazV_qH2h=uQrpTLbMRe2K7jVterSAr05w@mail.gmail.com>
To: "lightning-dev\\\\@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000034731405c0a538e3"
X-Mailman-Approved-At: Fri, 23 Apr 2021 15:51:18 +0000
Subject: [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: Fri, 23 Apr 2021 15:12:13 -0000

--00000000000034731405c0a538e3
Content-Type: text/plain; charset="UTF-8"

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

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

<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">https://github.com/ariard/L2-zool=
ogy</a><br>Still wip, but I&#39;ll have them in a good shape at agenda publ=
ication, with reading suggestions and open questions to structure discussio=
ns.<br>Also working on transaction pinning and mempool partitions attacks s=
imulations.<br><br>If L2s security/p2p/mempool is your jam, feel free to ge=
t involved :)<br><br>Cheers,<br>Antoine<br><br>[0] For e.g see optech secti=
on on transaction pinning attacks : <a href=3D"https://bitcoinops.org/en/to=
pics/transaction-pinning/">https://bitcoinops.org/en/topics/transaction-pin=
ning/</a><br>[1] <a href=3D"https://lists.linuxfoundation.org/pipermail/bit=
coin-dev/2020-September/018168.html">https://lists.linuxfoundation.org/pipe=
rmail/bitcoin-dev/2020-September/018168.html</a><br>[2] Lack of reference t=
ooling make it easier to have bug slip in like <a href=3D"https://lists.lin=
uxfoundation.org/pipermail/lightning-dev/2020-October/002858.html">https://=
lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002858.html<=
/a><br></div>

--00000000000034731405c0a538e3--