Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id A5671C000B for ; 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 ; 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 ; 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 ; Fri, 23 Apr 2021 16:17:48 +0000 (UTC) Received: by mail-yb1-xb2e.google.com with SMTP id p126so2607867yba.1 for ; 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: In-Reply-To: From: Bastien TEINTURIER Date: Fri, 23 Apr 2021 18:17:36 +0200 Message-ID: To: Antoine Riard Content-Type: multipart/alternative; boundary="000000000000fce50605c0a62245" X-Mailman-Approved-At: Fri, 23 Apr 2021 17:08:03 +0000 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 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 = 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 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 >> 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
Great idea, I'll join as well.
Thanks for setting = this in motion.

Le=C2=A0ven. 23 avr. 2021 =C3=A0=C2=A017:39, Antoine R= iard <antoine.riard@gmail.com= > a =C3=A9crit=C2=A0:
Hi Jeremy,

Yes dates a= re floating for now. After Bitcoin 2021, sounds a good idea.

A= wesome, I'll be really interested to review again an improved version o= f sponsorship. And I'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 :)

Le=C2=A0ven. 23 avr. 2021 =C3=A0=C2=A011= :25, Jeremy <jlrubi= n@mit.edu> a =C3=A9crit=C2=A0:
I'd be excited to join. Re= commend bumping the date=C2=A0 to mid June, if that's ok, as many Ameri= cans 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 controvers= ial, this would be a great place to discuss those tradeoffs.=C2=A0

<= div class=3D"gmail_quote" dir=3D"auto">
On Fri, Apr 23, 2021, 8:17 AM Antoine Riard <antoine.riard@gmail.com> wrote:<= br>
Hi,

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.

Unfortuna= tely, I don't think we'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'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.

# Scope

I would li= ke to propose the following 4 items as topics of discussion.

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.

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.

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.

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'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's poli= cy 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 top= ics related to tx-relay or mempools improvements towards L2s before to prop= ose a finalized scope and agenda.

# Goals

1) Reaching technic= al 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 th= e future.
4) Establishing a philosophy design and associated documentati= ons (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: I= RC meetings

As the problem space is savagely wide, I've started = a collection of documents to assist this workshop : https://gith= ub.com/ariard/L2-zoology
Still wip, but I'll have them in a good= shape at agenda publication, with reading suggestions and open questions t= o 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.li= nuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
[= 2] Lack of reference tooling make it easier to have bug slip in like https://lists.linuxfound= ation.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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/ma= ilman/listinfo/lightning-dev
--000000000000fce50605c0a62245--