Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7C654C000B; Fri, 23 Apr 2021 15:39:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 6A1C6400A7; Fri, 23 Apr 2021 15:39:31 +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 VduKLq52AbQi; Fri, 23 Apr 2021 15:39:29 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) by smtp2.osuosl.org (Postfix) with ESMTPS id 2256A400D7; Fri, 23 Apr 2021 15:39:29 +0000 (UTC) Received: by mail-wr1-x429.google.com with SMTP id p6so42158496wrn.9; Fri, 23 Apr 2021 08:39:28 -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=4CPsG5NQB1SZkSubcvaRzkuDsgJ3SW/mB0UvHUfkrfA=; b=qF9k9oqt64K7Y7HmscFIZ3YX2U0UrZyVBaMMYL+H9X1tQT6KSFBQSLH23G/qtXitYS OQ2bWHqktucXS5+CCN3rn4/beEkOoCdw+4sWWEBrwNryb2JTVTrV3yRzinZfRj9NHzVc hK4Rr3viYloGqQ/dO3yDti+V+5M2Lids/4/6CtrnI/8HNwD47xO17CUdTfjktsFhKBOj m+BdS3UscFu6O+fQL8VkPurWFusgVKpIezi1yqmS+k5gID1AoCBZ+31uqkdInQzQ4AoS HjUzkfIyZCf2aYXX5PvAiFTfMyY32L5MrzhZOqMVeHEkLPY+UA0LQDTg0wLBVMPNXF+e MGrw== 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=4CPsG5NQB1SZkSubcvaRzkuDsgJ3SW/mB0UvHUfkrfA=; b=SmqxiYFEWTzdk8QsK/oteeybw4gZBnCtw31QxIkgUz+H1QFJzguGoMnz1vAyrnbhX8 paH2kW0JB7t7O7XCTO0vLeJLYqQiAfHg/SC1E86Zg6DxiyNH7WseyzXuOojKZW7XGXq7 1FyEF0oRcoEqajy8KGIIOgcdbYWu/mOaoUuM/jk8uPVteig8oQ4x4C3E6Xvu5qnOXwhM 6Ouhbp3EKoRj86UgrVnQQab8V3VLgrZaDWczFHojQGRsh78r9iwXFX8CvYbq7Y/K0qTe xAG9W8yJKkAJfNyJNxjhrdLTCBl6p4slLcRrn4ozI3+FY7T0RnJpogf/gO+UJH4WCeRf 8dRQ== X-Gm-Message-State: AOAM530ehjHVKriE7V9QmjNAlnHxUWdjEaVjSoY+LzhWBwcOlGyviwSq 8/PVFhUvEt6YecnqARYS5qGcnDC1NvODcHlbBsqd4qv775w= X-Google-Smtp-Source: ABdhPJxnyNNlNGlf5qSIshqJyJ3pB6IbtfRETPbwHZmuTvmz6X480aWHb0NCcMgftByTTm84Af/9lFTZkAsj8cIBQGU= X-Received: by 2002:a05:6000:8b:: with SMTP id m11mr5501459wrx.224.1619192367353; Fri, 23 Apr 2021 08:39:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Fri, 23 Apr 2021 11:39:15 -0400 Message-ID: To: Jeremy Content-Type: multipart/alternative; boundary="000000000000e1102005c0a599b9" X-Mailman-Approved-At: Fri, 23 Apr 2021 15:51:18 +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 15:39:31 -0000 --000000000000e1102005c0a599b9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 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 >> _______________________________________________ >> Lightning-dev mailing list >> Lightning-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > --000000000000e1102005c0a599b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeremy,

Yes dates are floating f= or 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 whic= h was floating around last year during pinnings discussions. Yet another se= t of trade-offs :)

Le=C2=A0ven. 23 avr. 2021 =C3=A0=C2=A011:25, Jeremy &= lt;jlrubin@mit.edu> a =C3=A9crit= =C2=A0:
I'd be excited to join. Recommend bumping the date=C2=A0= to mid June, if that's ok, as many Americans will be at Bitcoin 2021.<= /div>

I was thinking about rev= iving the sponsors proposal with a 100 block lock on spending a sponsoring = tx which would hopefully make less controversial, this would be a great pla= ce to discuss those tradeoffs.=C2=A0

On Fri, Apr 23, 2021, 8:17 = AM Antoine Riard <antoine.riard@gmail.com> wrote:
Hi,

During the lastes= t 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 improve= ments 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 advance= ments, 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 de= vs to make exchange fruitful.

Unfortunately, I don't think we= 9;ll be able to organize such in-person workshops this year (because you kn= ow travel is hard those days...) As a substitution, I'm proposing a ser= ies 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 f= it in a room.

# Scope

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

1) Package relay design or another g= eneric L2 fee-bumping primitive like sponsorship [0]. IMHO, this primitive = should at least solve mempools spikes making obsolete propagation of transa= ctions with pre-signed feerate, solve pinning attacks compromising Lightnin= g/multi-party contract protocol safety, offer an usable and stable API to L= 2 software stack, stay compatible with miner and full-node operators incent= ives and obviously minimize CPU/memory DoS vectors.

2) Deprecation o= f opt-in RBF toward full-rbf. Opt-in RBF makes it trivial for an attacker t= o partition network mempools in divergent subsets and from then launch adva= nced security or privacy attacks against a Lightning node. Note, it might a= lso 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 sho= uld be ready to upgrade their protocols in emergency in coordination with b= ase layers developers.

4) Guidelines about L2 protocols onchain secu= rity design. Currently deployed like Lightning are making a bunch of assump= tions on tx-relay and mempool acceptances rules. Those rules are non-normat= ive, non-reliable and lack documentation. Further, they're devoid of to= oling to enforce them at runtime [2]. IMHO, it could be preferable to ident= ify a subset of them on which second-layers protocols can do assumptions wi= thout encroaching too much on nodes's policy realm or making the base l= ayer development in those areas too cumbersome.

I'm aware that s= ome folks are interested in other topics such as extension of Core's me= mpools 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 me= mpools improvements towards L2s before to propose a finalized scope and age= nda.

# Goals

1) Reaching technical consensus.
2) Reaching = technical consensus, before seeking community consensus as it likely has ec= osystem-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
202= 1-05-07: End of concertation period
2021-05-10: Proposition of workshop = agenda and schedule
late 2021-05/2021-06: IRC meetings

As the pro= blem space is savagely wide, I've started a collection of documents to = assist this workshop : https://github.com/ariard/L2-zoology<= br>Still wip, but I'll have them in a good shape at agenda publication,= with reading suggestions and open questions to structure discussions.
A= lso working on transaction pinning and mempool partitions attacks simulatio= ns.

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

Cheers,
Antoine

[0] For e.g see optech section on tr= ansaction pinning attacks : https://bitcoinops.= org/en/topics/transaction-pinning/
[1] https://lists.linuxfoundation.org/pipermail/bit= coin-dev/2020-September/018168.html
[2] Lack of reference tooling ma= ke it easier to have bug slip in like https://lists.linuxfoundation.org/pipermail/lightning-d= ev/2020-October/002858.html
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfounda= tion.org/mailman/listinfo/lightning-dev
--000000000000e1102005c0a599b9--