From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id EC4C1C000B for ; Mon, 26 Apr 2021 23:06:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id DAA9740534 for ; Mon, 26 Apr 2021 23:06:48 +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: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmT7o47Pk_di for ; Mon, 26 Apr 2021 23:06:47 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) by smtp4.osuosl.org (Postfix) with ESMTPS id F154C4053A for ; Mon, 26 Apr 2021 23:06:46 +0000 (UTC) Received: by mail-yb1-xb35.google.com with SMTP id c195so66968989ybf.9 for ; Mon, 26 Apr 2021 16:06:46 -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; bh=v9z/OUsMib9lvjxKEmeGS7AG/xSU/am0OZTvx/J1DQc=; b=RMf/ySmWA2UaP+bNboWO4kN+B3ZWq9KNQ2hnfxKYiRRvuWgAKDw5sKTmolrgqH09nV r8qaFtCPjRGq4cPUoetJjyS0RvJiJpbO+tqvZnb0xmsc+fgDJB4u4doNHKzIdl1afVSv P4Wg76T/PqAz2DMI/uz4X8/cfDDjqGnVxgUgGeM+epz5y+qI4l8w+KYv534hVZtjk4EA AxCTItKSMUOEnux2Erxhn+F1UMv743/fZmWTV8X2ovlTdzU13mzALgSgwrwLnWjs1DP7 ClBvq+m1PCllAiV5WL1W1tQPMzE/FiJELhLCbYV1O85TdcPDRdpWKj6kMKivQlgHHyRw l09Q== 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; bh=v9z/OUsMib9lvjxKEmeGS7AG/xSU/am0OZTvx/J1DQc=; b=Y4b2VlKWLDFgBUb23PcKZFDk2dgC2EI5WH3pNbLvfpLyQPXDWDpx9EFeKlH6JYYy0g KoTRh6RNGR9wW13A6lCES5wjy9CAnf14W4tJgp52y+MyK3PKwSaNLA1JvPFwreStg6W8 36LNciE0+51A7Esrfze2rs2ZJghrFZrw8CZjebIPgnr0JOMInHBl7E7Vt4lha4DuoWz5 erMl82Poz6q1PhyCBfWJ8sXONyqhJXqMduIEAv+ZmQQlepAVmVQwSPnOqBaPvMvIrHEY rlRAoI6YEGPl+YrjWpQUQG1vkWgITRPBTPjGHlHqthS8QuCfD7qWdbWxEU8K/OUNUylR r+5g== X-Gm-Message-State: AOAM5303SXtAZeFFDi4Gn6Jss6uDV4ZoY06DoPePGJvidAwWfmbjnP5X /KtJMaW9o5QMb6efFYmUTJQFDQwG4aIUqUd/BWeUJQr14Z4= X-Google-Smtp-Source: ABdhPJyPYX7a5sEtG7XP7Gj8ahCRiqsWX18Z5mFNEuShJLp7gCXdG4Umsgh7ZlASVDDxwH14Er9Qu1Gs+L75K5mez7Y= X-Received: by 2002:a25:d40d:: with SMTP id m13mr20021ybf.170.1619478405906; Mon, 26 Apr 2021 16:06:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Gloria Zhao Date: Mon, 26 Apr 2021 16:06:34 -0700 Message-ID: To: Antoine Riard , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000001b024b05c0e833ec" X-Mailman-Approved-At: Mon, 26 Apr 2021 23:17:13 +0000 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2021 23:06:49 -0000 --0000000000001b024b05c0e833ec Content-Type: text/plain; charset="UTF-8" Hi Antoine, Thanks for initiating this! I'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 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 of 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 ) 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 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 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000001b024b05c0e833ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Antoine,

Thanks for initiating this! I'm interested in joining. Since I mostly = live in L1, my primary goal is to understand what simplest version of packa= ge relay would be sufficient to support transaction relay assumptions made = by L2 applications. For example, if a parent + child package covers the vas= t 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) s= hould be separate discussions.

Re: L2-zoology... I= n general, for the purpose of creating a stable API / set of assumptions be= tween layers, I'd like to be as concrete as possible. Speaking for myse= lf, if I'm TDDing for a specific L2 attack, I need test vectors. A simp= le 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 of tooling to= build L2 transactions in Bitcoin Core. In the other direction, it's h= ard to make any guarantees given the complexity of mempool policy, but perh= aps it could be helpful to expose a configurable RPC (e.g. #21413) to test a range of sc= enarios?

Anyway, looking forward to discussions :)=

Best,
Gloria

On Fri, Apr 2= 3, 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 acc= eptances rules of the base layer have been sources of major security and op= erational concerns for Lightning and other Bitcoin second-layers [0]. I thi= nk those areas require significant improvements to ease design and deployme= nt 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 fe= w 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
<= br>I would like to propose the following 4 items as topics of discussion.
1) Package relay design or another generic L2 fee-bumping primitive l= ike sponsorship [0]. IMHO, this primitive should at least solve mempools sp= ikes making obsolete propagation of transactions with pre-signed feerate, s= olve pinning attacks compromising Lightning/multi-party contract protocol s= afety, offer an usable and stable API to L2 software stack, stay compatible= with miner and full-node operators incentives and obviously minimize CPU/m= emory 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 d= ivergent subsets and from then launch advanced security or privacy attacks = against a Lightning node. Note, it might also be a concern for bandwidth bl= eeding attacks against L1 nodes.

3) Guidelines about coordinated cro= ss-layers security disclosures. Mitigating a security issue around tx-relay= or the mempool in Core might have harmful implications for downstream proj= ects. Ideally, L2 projects maintainers should be ready to upgrade their pro= tocols in emergency in coordination with base layers developers.

4) = Guidelines about L2 protocols onchain security design. Currently deployed l= ike Lightning are making a bunch of assumptions on tx-relay and mempool acc= eptances rules. Those rules are non-normative, non-reliable and lack docume= ntation. 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 sec= ond-layers protocols can do assumptions without encroaching too much on nod= es's policy realm or making the base layer development in those areas t= oo cumbersome.

I'm aware that some folks are interested in other= topics such as extension of Core's mempools package limits or better p= ricing of RBF replacement. So l propose a 2-week concertation period to sub= mit other topics related to tx-relay or mempools improvements towards L2s b= efore to propose a finalized scope and agenda.

# Goals

1) Rea= ching technical consensus.
2) Reaching technical consensus, before seeki= ng community consensus as it likely has ecosystem-wide implications.
3) = Establishing a security incident response policy which can be applied by de= v teams in the future.
4) Establishing a philosophy design and associate= d documentations (BIPs, best practices, ...)

# Timeline

2021-= 04-23: Start of concertation period
2021-05-07: End of concertation peri= od
2021-05-10: Proposition of workshop agenda and schedule
late 2021-= 05/2021-06: IRC meetings

As the problem space is savagely wide, I= 9;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 stru= cture discussions.
Also working on transaction pinning and mempool parti= tions attacks simulations.

If L2s security/p2p/mempool is your jam, = feel free to get involved :)

Cheers,
Antoine

[0] For e.g s= ee optech section on transaction pinning attacks : https://bitcoin= ops.org/en/topics/transaction-pinning/
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-S= eptember/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 _______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000001b024b05c0e833ec--