{"type":"rich","version":"1.0","author_name":"npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","author_url":"https://nostr.ae/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-04-23\n📝 Original message:\nHi,\n\nDuring the lastest years, tx-relay and mempool acceptances rules of the\nbase layer have been sources of major security and operational concerns for\nLightning and other Bitcoin second-layers [0]. I think those areas require\nsignificant improvements to ease design and deployment of higher Bitcoin\nlayers and I believe this opinion is shared among the L2 dev community. In\norder to make advancements, it has been discussed a few times in the last\nmonths to organize in-person workshops to discuss those issues with the\npresence of both L1/L2 devs to make exchange fruitful.\n\nUnfortunately, I don't think we'll be able to organize such in-person\nworkshops this year (because you know travel is hard those days...) As a\nsubstitution, I'm proposing a series of one or more irc meetings. That\nsaid, this substitution has the happy benefit to gather far more folks\ninterested by those issues that you can fit in a room.\n\n# Scope\n\nI would like to propose the following 4 items as topics of discussion.\n\n1) Package relay design or another generic L2 fee-bumping primitive like\nsponsorship [0]. IMHO, this primitive should at least solve mempools spikes\nmaking obsolete propagation of transactions with pre-signed feerate, solve\npinning attacks compromising Lightning/multi-party contract protocol\nsafety, offer an usable and stable API to L2 software stack, stay\ncompatible with miner and full-node operators incentives and obviously\nminimize CPU/memory DoS vectors.\n\n2) Deprecation of opt-in RBF toward full-rbf. Opt-in RBF makes it trivial\nfor an attacker to partition network mempools in divergent subsets and from\nthen launch advanced security or privacy attacks against a Lightning node.\nNote, it might also be a concern for bandwidth bleeding attacks against L1\nnodes.\n\n3) Guidelines about coordinated cross-layers security disclosures.\nMitigating a security issue around tx-relay or the mempool in Core might\nhave harmful implications for downstream projects. Ideally, L2 projects\nmaintainers should be ready to upgrade their protocols in emergency in\ncoordination with base layers developers.\n\n4) Guidelines about L2 protocols onchain security design. Currently\ndeployed like Lightning are making a bunch of assumptions on tx-relay and\nmempool acceptances rules. Those rules are non-normative, non-reliable and\nlack documentation. Further, they're devoid of tooling to enforce them at\nruntime [2]. IMHO, it could be preferable to identify a subset of them on\nwhich second-layers protocols can do assumptions without encroaching too\nmuch on nodes's policy realm or making the base layer development in those\nareas too cumbersome.\n\nI'm aware that some folks are interested in other topics such as extension\nof Core's mempools package limits or better pricing of RBF replacement. So\nl propose a 2-week concertation period to submit other topics related to\ntx-relay or mempools improvements towards L2s before to propose a finalized\nscope and agenda.\n\n# Goals\n\n1) Reaching technical consensus.\n2) Reaching technical consensus, before seeking community consensus as it\nlikely has ecosystem-wide implications.\n3) Establishing a security incident response policy which can be applied by\ndev teams in the future.\n4) Establishing a philosophy design and associated documentations (BIPs,\nbest practices, ...)\n\n# Timeline\n\n2021-04-23: Start of concertation period\n2021-05-07: End of concertation period\n2021-05-10: Proposition of workshop agenda and schedule\nlate 2021-05/2021-06: IRC meetings\n\nAs the problem space is savagely wide, I've started a collection of\ndocuments to assist this workshop : https://github.com/ariard/L2-zoology\nStill wip, but I'll have them in a good shape at agenda publication, with\nreading suggestions and open questions to structure discussions.\nAlso working on transaction pinning and mempool partitions attacks\nsimulations.\n\nIf L2s security/p2p/mempool is your jam, feel free to get involved :)\n\nCheers,\nAntoine\n\n[0] For e.g see optech section on transaction pinning attacks :\nhttps://bitcoinops.org/en/topics/transaction-pinning/\n[1]\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html\n[2] Lack of reference tooling make it easier to have bug slip in like\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002858.html\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210423/98e1f2cc/attachment.html\u003e"}