You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Following my proposal made on the lightning mailing list over the last months to organize and host LN Summit 2024.
Here the following informations already:
geographical location: South France, exact location TBD
timing: June 2024, exact week TBD
length: 3 days
group size: ~35 people (main implems LND / CLN / Eclair / LDK / Electrum + non-affiliated LN researchers)
On consensus changes, we start to have things like feerate-dependent timelocks, per-block median feerate, HTLC aggregations and maybe reverse-timelocks that would clean a lot of weaknesses in Lightning and Bitcoin second-layers, if we can design, develop and deploy them smoothly over the coming decade. As for now Lightning is the most-advanced L2, I think it’s valuable to spend a bit of time ensuring any technical-debt fixing consensus change works at least correctly for Lightning. Design process that can happen in parallel to weight other Bitcoin second-layers.
There is a private chat group with Bastien Teinturier and Lisa Neigut to oversight my organization of the LN Summit. It will be appreciated to have one representant from LDK and one from LND to ensure the respect of the usual formalities related to FOSS events organization.
If for any reason, you cannot attend this edition of the LN Summit, I wish to convey you this is okay. Given the growth of the LN ecosystem and its development community over the last years, the time has came where it might be opportune to organize 2 LN Summit editions a year, as this is the usual frequency for Coredev events. I'll note that increasing of LN Summit frequency would allow to encompass folks working on LSPs specifications and implementations, while they might not be the most relevant domain experts in term of L2 consensus changes. From my experience attending summit and Coredevs over the last years, I think you still have an in-person efficiency coordination bottleneck above the ceiling of a group of 30 to 40 people.
Finally, I'll ask to anyone participating to the LN summit and actively doing security research on the protocol or its main implementations to withhold the public disclosure of any security issue (unless grounded emergency) 15 days before and 15 days after the LN Summit happening. I'll bind myself to those rules in the hypothetical situation of discovering new LN security issues before June. Lessons from the Zurich edition here and somehow respecting the canonical standards of mainstream infosec conferences.
Public comments or suggestions on this edition of the LN Summit organization are welcome.
Edit (22/12/2024): actually per-block median feerate and feerate-dependent-timelock can solve many lightning security issues and i’m getting more and more enthusiast on organizing one or more LN summits to roll the ball efficiently on this.
The text was updated successfully, but these errors were encountered:
Finally no. This is not in my habitude to withdraw my words, though here it’s better for doing it. I just don’t have sufficient trust and confidence remaining in the LN community at large.
I did open the hand privately to some people in this community. The day there is satisfying communication again I might change my mind and I’ll think to contribute back. Realistically, this will take a lot of time if ever it happens and this is not wise to meddle interests in parallel.
In the meantime, good luck to the LN community to coordinate security issues and rolling out imperative consensus changes for LN without my help. Closing #772 for good this time.
(In the hypothesis of still being in knowledge of non-disclosed practical LN vulnerabilities I’ll publish them under pseudonymous 90 days after notification to LN maintainers).
Following my proposal made on the lightning mailing list over the last months to organize and host LN Summit 2024.
Here the following informations already:
On consensus changes, we start to have things like feerate-dependent timelocks, per-block median feerate, HTLC aggregations and maybe reverse-timelocks that would clean a lot of weaknesses in Lightning and Bitcoin second-layers, if we can design, develop and deploy them smoothly over the coming decade. As for now Lightning is the most-advanced L2, I think it’s valuable to spend a bit of time ensuring any technical-debt fixing consensus change works at least correctly for Lightning. Design process that can happen in parallel to weight other Bitcoin second-layers.
There is a private chat group with Bastien Teinturier and Lisa Neigut to oversight my organization of the LN Summit. It will be appreciated to have one representant from LDK and one from LND to ensure the respect of the usual formalities related to FOSS events organization.
If for any reason, you cannot attend this edition of the LN Summit, I wish to convey you this is okay. Given the growth of the LN ecosystem and its development community over the last years, the time has came where it might be opportune to organize 2 LN Summit editions a year, as this is the usual frequency for Coredev events. I'll note that increasing of LN Summit frequency would allow to encompass folks working on LSPs specifications and implementations, while they might not be the most relevant domain experts in term of L2 consensus changes. From my experience attending summit and Coredevs over the last years, I think you still have an in-person efficiency coordination bottleneck above the ceiling of a group of 30 to 40 people.
Finally, I'll ask to anyone participating to the LN summit and actively doing security research on the protocol or its main implementations to withhold the public disclosure of any security issue (unless grounded emergency) 15 days before and 15 days after the LN Summit happening. I'll bind myself to those rules in the hypothetical situation of discovering new LN security issues before June. Lessons from the Zurich edition here and somehow respecting the canonical standards of mainstream infosec conferences.
Public comments or suggestions on this edition of the LN Summit organization are welcome.
Edit (22/12/2024): actually per-block median feerate and feerate-dependent-timelock can solve many lightning security issues and i’m getting more and more enthusiast on organizing one or more LN summits to roll the ball efficiently on this.
The text was updated successfully, but these errors were encountered: