From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id C3E13C000B; Fri, 23 Apr 2021 15:25:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id BFD9640645; Fri, 23 Apr 2021 15:25:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 IrnDNBPESG2V; Fri, 23 Apr 2021 15:25:34 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp2.osuosl.org (Postfix) with ESMTPS id 2A75E40640; Fri, 23 Apr 2021 15:25:33 +0000 (UTC) Received: from mail-il1-f174.google.com (mail-il1-f174.google.com [209.85.166.174]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 13NFPWrF020166 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 23 Apr 2021 11:25:32 -0400 Received: by mail-il1-f174.google.com with SMTP id y10so279589ilv.0; Fri, 23 Apr 2021 08:25:32 -0700 (PDT) X-Gm-Message-State: AOAM532gu3kMVwQcAtzicaEG+TIQkFLSUQ0MAZpGkF7IHqUDsDJ715A7 OJnx/LmiUewDqaQNloAuY5JkD4m1E5ifHlhgSbk= X-Google-Smtp-Source: ABdhPJxEl3l291GCYAfg7j160ka0fbYctkpWJkXbdKpLTIw38G0BnjrSkZIUF2pAu7Szs7CyAbpwYB0VzWLP0KofNgQ= X-Received: by 2002:a92:6e0e:: with SMTP id j14mr3401710ilc.90.1619191531778; Fri, 23 Apr 2021 08:25:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeremy Date: Fri, 23 Apr 2021 08:25:19 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Antoine Riard Content-Type: multipart/alternative; boundary="00000000000013385805c0a56834" Cc: Bitcoin Protocol Discussion , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2021 15:25:35 -0000 --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 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
I'd be excited to join. Recommend bumping the da= te=C2=A0 to mid June, if that's ok, as many Americans will be at Bitcoi= n 2021.

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

On Fri, Apr 23, 2021= , 8:17 AM Antoine Riard <anto= ine.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 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>
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 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.

# Scope
I would like to propose the following 4 items as topics of discussion= .

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.

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.

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.

= 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'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's policy realm or making the base layer development in those area= s too cumbersome.

I'm aware that some folks are interested in ot= her topics such as extension of Core'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.

# Goals

1) = Reaching technical consensus.
2) Reaching technical consensus, before se= eking 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 associ= ated documentations (BIPs, best practices, ...)

# Timeline

20= 21-04-23: Start of concertation period
2021-05-07: End of concertation p= eriod
2021-05-10: Proposition of workshop agenda and schedule
late 20= 21-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 hav= e them in a good shape at agenda publication, with reading suggestions and = open questions to structure discussions.
Also working on transaction pin= ning and mempool partitions attacks simulations.

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

Cheers,
Antoin= e

[0] For e.g see optech section on transaction pinning attacks : https://bitcoinops.org/en/topics/transaction-pinn= ing/
[1] ht= tps://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://li= sts.linuxfoundation.org/pipermail/lightning-dev/2020-October/002858.html
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfounda= tion.org/mailman/listinfo/lightning-dev
--00000000000013385805c0a56834--