Great idea, I'll join as well. Thanks for setting this in motion. Le ven. 23 avr. 2021 à 17:39, Antoine Riard a écrit : > 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 >>> >> _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >