đź“… Original date posted:2021-04-23
đź“ť Original message:
Great idea, I'll join as well.
Thanks for setting this in motion.
Le ven. 23 avr. 2021 Ă 17:39, Antoine Riard <antoine.riard at gmail.com> 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 <jlrubin at mit.edu> 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 <antoine.riard at gmail.com>
>> 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 at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210423/09108adc/attachment.html>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-09 13:02:21
in reply to nevent1q…2gt3
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-09 13:02:21Event JSON
{
"id": "23ccb2091a20dcf7e9591d4dd9947a6cbb7cdae80a9783678dd5d6cf073956f1",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1686315741,
"kind": 1,
"tags": [
[
"e",
"6df637172c852a80d29580e4144b94a751b334fb2f6502790e35c1ddab9359f7",
"",
"root"
],
[
"e",
"99ac6044910eff78792325bf70decdbffea47821dc09b22d3810efa3c8639214",
"",
"reply"
],
[
"p",
"6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551"
]
],
"content": "📅 Original date posted:2021-04-23\n📝 Original message:\nGreat idea, I'll join as well.\nThanks for setting this in motion.\n\nLe ven. 23 avr. 2021 à 17:39, Antoine Riard \u003cantoine.riard at gmail.com\u003e a\nécrit :\n\n\u003e Hi Jeremy,\n\u003e\n\u003e Yes dates are floating for now. After Bitcoin 2021, sounds a good idea.\n\u003e\n\u003e Awesome, I'll be really interested to review again an improved version of\n\u003e sponsorship. And I'll try to sketch out the sighash_no-input fee-bumping\n\u003e idea which was floating around last year during pinnings discussions. Yet\n\u003e another set of trade-offs :)\n\u003e\n\u003e Le ven. 23 avr. 2021 à 11:25, Jeremy \u003cjlrubin at mit.edu\u003e a écrit :\n\u003e\n\u003e\u003e I'd be excited to join. Recommend bumping the date to mid June, if\n\u003e\u003e that's ok, as many Americans will be at Bitcoin 2021.\n\u003e\u003e\n\u003e\u003e I was thinking about reviving the sponsors proposal with a 100 block lock\n\u003e\u003e on spending a sponsoring tx which would hopefully make less controversial,\n\u003e\u003e this would be a great place to discuss those tradeoffs.\n\u003e\u003e\n\u003e\u003e On Fri, Apr 23, 2021, 8:17 AM Antoine Riard \u003cantoine.riard at gmail.com\u003e\n\u003e\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e Hi,\n\u003e\u003e\u003e\n\u003e\u003e\u003e During the lastest years, tx-relay and mempool acceptances rules of the\n\u003e\u003e\u003e base layer have been sources of major security and operational concerns for\n\u003e\u003e\u003e Lightning and other Bitcoin second-layers [0]. I think those areas require\n\u003e\u003e\u003e significant improvements to ease design and deployment of higher Bitcoin\n\u003e\u003e\u003e layers and I believe this opinion is shared among the L2 dev community. In\n\u003e\u003e\u003e order to make advancements, it has been discussed a few times in the last\n\u003e\u003e\u003e months to organize in-person workshops to discuss those issues with the\n\u003e\u003e\u003e presence of both L1/L2 devs to make exchange fruitful.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Unfortunately, I don't think we'll be able to organize such in-person\n\u003e\u003e\u003e workshops this year (because you know travel is hard those days...) As a\n\u003e\u003e\u003e substitution, I'm proposing a series of one or more irc meetings. That\n\u003e\u003e\u003e said, this substitution has the happy benefit to gather far more folks\n\u003e\u003e\u003e interested by those issues that you can fit in a room.\n\u003e\u003e\u003e\n\u003e\u003e\u003e # Scope\n\u003e\u003e\u003e\n\u003e\u003e\u003e I would like to propose the following 4 items as topics of discussion.\n\u003e\u003e\u003e\n\u003e\u003e\u003e 1) Package relay design or another generic L2 fee-bumping primitive like\n\u003e\u003e\u003e sponsorship [0]. IMHO, this primitive should at least solve mempools spikes\n\u003e\u003e\u003e making obsolete propagation of transactions with pre-signed feerate, solve\n\u003e\u003e\u003e pinning attacks compromising Lightning/multi-party contract protocol\n\u003e\u003e\u003e safety, offer an usable and stable API to L2 software stack, stay\n\u003e\u003e\u003e compatible with miner and full-node operators incentives and obviously\n\u003e\u003e\u003e minimize CPU/memory DoS vectors.\n\u003e\u003e\u003e\n\u003e\u003e\u003e 2) Deprecation of opt-in RBF toward full-rbf. Opt-in RBF makes it\n\u003e\u003e\u003e trivial for an attacker to partition network mempools in divergent subsets\n\u003e\u003e\u003e and from then launch advanced security or privacy attacks against a\n\u003e\u003e\u003e Lightning node. Note, it might also be a concern for bandwidth bleeding\n\u003e\u003e\u003e attacks against L1 nodes.\n\u003e\u003e\u003e\n\u003e\u003e\u003e 3) Guidelines about coordinated cross-layers security disclosures.\n\u003e\u003e\u003e Mitigating a security issue around tx-relay or the mempool in Core might\n\u003e\u003e\u003e have harmful implications for downstream projects. Ideally, L2 projects\n\u003e\u003e\u003e maintainers should be ready to upgrade their protocols in emergency in\n\u003e\u003e\u003e coordination with base layers developers.\n\u003e\u003e\u003e\n\u003e\u003e\u003e 4) Guidelines about L2 protocols onchain security design. Currently\n\u003e\u003e\u003e deployed like Lightning are making a bunch of assumptions on tx-relay and\n\u003e\u003e\u003e mempool acceptances rules. Those rules are non-normative, non-reliable and\n\u003e\u003e\u003e lack documentation. Further, they're devoid of tooling to enforce them at\n\u003e\u003e\u003e runtime [2]. IMHO, it could be preferable to identify a subset of them on\n\u003e\u003e\u003e which second-layers protocols can do assumptions without encroaching too\n\u003e\u003e\u003e much on nodes's policy realm or making the base layer development in those\n\u003e\u003e\u003e areas too cumbersome.\n\u003e\u003e\u003e\n\u003e\u003e\u003e I'm aware that some folks are interested in other topics such as\n\u003e\u003e\u003e extension of Core's mempools package limits or better pricing of RBF\n\u003e\u003e\u003e replacement. So l propose a 2-week concertation period to submit other\n\u003e\u003e\u003e topics related to tx-relay or mempools improvements towards L2s before to\n\u003e\u003e\u003e propose a finalized scope and agenda.\n\u003e\u003e\u003e\n\u003e\u003e\u003e # Goals\n\u003e\u003e\u003e\n\u003e\u003e\u003e 1) Reaching technical consensus.\n\u003e\u003e\u003e 2) Reaching technical consensus, before seeking community consensus as\n\u003e\u003e\u003e it likely has ecosystem-wide implications.\n\u003e\u003e\u003e 3) Establishing a security incident response policy which can be applied\n\u003e\u003e\u003e by dev teams in the future.\n\u003e\u003e\u003e 4) Establishing a philosophy design and associated documentations (BIPs,\n\u003e\u003e\u003e best practices, ...)\n\u003e\u003e\u003e\n\u003e\u003e\u003e # Timeline\n\u003e\u003e\u003e\n\u003e\u003e\u003e 2021-04-23: Start of concertation period\n\u003e\u003e\u003e 2021-05-07: End of concertation period\n\u003e\u003e\u003e 2021-05-10: Proposition of workshop agenda and schedule\n\u003e\u003e\u003e late 2021-05/2021-06: IRC meetings\n\u003e\u003e\u003e\n\u003e\u003e\u003e As the problem space is savagely wide, I've started a collection of\n\u003e\u003e\u003e documents to assist this workshop : https://github.com/ariard/L2-zoology\n\u003e\u003e\u003e Still wip, but I'll have them in a good shape at agenda publication,\n\u003e\u003e\u003e with reading suggestions and open questions to structure discussions.\n\u003e\u003e\u003e Also working on transaction pinning and mempool partitions attacks\n\u003e\u003e\u003e simulations.\n\u003e\u003e\u003e\n\u003e\u003e\u003e If L2s security/p2p/mempool is your jam, feel free to get involved :)\n\u003e\u003e\u003e\n\u003e\u003e\u003e Cheers,\n\u003e\u003e\u003e Antoine\n\u003e\u003e\u003e\n\u003e\u003e\u003e [0] For e.g see optech section on transaction pinning attacks :\n\u003e\u003e\u003e https://bitcoinops.org/en/topics/transaction-pinning/\n\u003e\u003e\u003e [1]\n\u003e\u003e\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html\n\u003e\u003e\u003e [2] Lack of reference tooling make it easier to have bug slip in like\n\u003e\u003e\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002858.html\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e Lightning-dev mailing list\n\u003e\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210423/09108adc/attachment.html\u003e",
"sig": "ade25066bb07959371908feb6476cdfbcf2b4796e051f6ab906504f966e89888c557fe13e4641739cb135e9a303e1f6fd9550a85786edf4bc87f8b886a91bb46"
}