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 à 11:25, Jeremy a écrit : > 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 >> >