Lightning Dev Summit Topics

[carlaKC]

Tracking issue to collect the topics that folks are interested in disucssing during the lightning dev summit in June.

Please submit topics that you would like to discuss in the comments.

General Guidelines:

• Where possible, please try to post topics in advance so that other attendees have time to prepare!
• Short summaries and links to additional resources relevant to your topic are very helpful.
• Feel free to post a topic you're interested in even if you don't want to present/lead discussion on it.
• Please make a note if you need special equipement of some sort (we'll have whiteboards and a projector)

The notes from last year's summit can be found here.

[vincenzopalazzo]

I would like to have a discussion on the trampoline #829

I was planning to take this feature on after the summer so it may be a good discussion for me that I arrived after this feature is proposed :)

P.S: Thanks to open the issue

[t-bast]

Splicing

Splicing has made a lot of progress since last year, with two implementations almost ready for cross-compatibility testing:

• eclair (directly on the master branch, gated by an experimental feature bit)
• cln (splicing: Adds the features needed to enable collaborative splicing & resizing of active channels. ElementsProject/lightning#6253)

Splicing has a lot of subtle implications for lightning nodes/wallets: it will be interesting to discuss them together!

Blinded paths

Blinded paths have been added to the specification already, but they have a lot of non-trivial implementation details.
It will be useful to spend some time discussing them and sharing ideas on algorithms for path selection.

High on-chain fees

We've just spent many days of crazy high and sustained on-chain fees.
This has created a lot of issues for lightning wallets, highlighting parts of lightning that are still too correlated to on-chain fees.
I'd like to discuss:

• what we can do today to improve usability without sacrificing funds safety
• how we fix that tomorrow (hint: package relay)

Channel jamming

We were all hoping channel jamming would be fixed already, but surprise surprise, it's not!
However, some progress was made on ideas to try to mitigate jamming.
Let's coordinate to start shipping some data collection to try these ideas in the wild.

Trampoline payments

Trampoline payments are a great way to simplify graph management requirements and payment reliability for edge nodes (e.g. wallets), while giving routing nodes the opportunity to offer path-finding-as-a-service (which lets them receive more fees and data about path-finding success). This can be a wide topic, but I think the simplest use-case for it is compelling enough to see it implemented. The code changes are actually quite simple (much simpler than route blinding!).

There are two PRs:

• Trampoline onion format (Feature 56/57) #836
• Trampoline Routing (2021 edition) (Feature 56/57) #829

I'll update the presentation I made for the last summit, to fix what people found unclear last year, it can help to have some visual support while discussing this.

[joostjager]

Attributable errors

Fixes error attribution to make Lightning pathfinding safer and more accurate. Additionally, routing nodes get the opportunity to attach metadata to failure packets. This can be used to convey timing information back to the sender, allowing scoring based on node latency.

Spec PR: #1044

(Partial) implementations:

• LND: routing: inbound fees send support lightningnetwork/lnd#6934
• Eclair: Attributable errors ACINQ/eclair#2519
• Rust-lightning: Convert to attributable errors lightningdevkit/rust-lightning#2256

[valentinewallace]

Async Payments

Allows often-offline senders and receivers to send and receive payments reliably. Largely useful for mobile noncustodial lightning users.

Initial spec PR: #989. This is about 1/5 of what’s needed.

@remeyers made this nice user story: https://gist.github.com/remyers/e0d2bedb7bc87371d1bdbbb6fff2edd1 and an overview of LDK’s implementation plan was discussed in the LDK Roadmap. Progress will be tracked here.

The current thinking is to base async payments on BOLT 12, which will need some spec modifications because we don't want to trust LSPs to provide regular invoices on behalf of users. The current solution to this loses PoP, but we can get that back when we have PTLCs, see this thread https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-January/003831.html.

[instagibbs]

how we fix that tomorrow (hint: package relay)

would also like to discuss protocol updates in light of package relay, including smaller things like feature bit disabling update_fee

[t-bast]

would also like to discuss protocol updates in light of package relay, including smaller things like feature bit disabling update_fee

That's exactly what I had in mind: making commit txs pay 0 fees and all the impacts it has on the protocol and implementation (it simplifies a ton of things!).

[rustyrussell]

1. simplified commitment Feature 106/107: option_simplified_update. #867
   • There have been more reports of desynchronization :(
   • Minimal changes for existing code, but massive win once non-simplified is removed.
   • @instagibbs's Eltoo prototype uses this approach already
2. gossip v1.5 vs 2
   • Basically, do ownership proofs go in node_announcement or channel_announcement?
   • Can we do TXOs (easy to prove to lite nodes)? Stick with UTXOs (simple to model)? Do we allow a multiplier (better for obfuscating sources)?
   • Can we do generic taproot spendability proofs? (Futureproof against other channel constructions)
   • How do we retro in v1? (Then we can unify on new-style gossip)

[moneyball]

1. BOLT 12 Onion Messages DoS mitigation strategy

• What have we learned in the past year (simulations, implementations in CLN, Eclair, LDK, LNDK)?
• Are there remaining concerns? What are good next steps?

2. Eltoo / APO

• What is the latest sentiment from folks about this direction?
• Penalties or no?
• Is it realistic for LN implementations to prioritize this in 2024? (and thus, should we be pushing for an APO soft fork now?)

3. Standard interfaces between applications and LN wallets

• Discuss pros/cons and risks of various approaches (Greenlight server API + push notification approach, mobile intents approach, etc.)
• Multi-device access to a LN wallet (Greenlight server API approach, VSS approach, etc.)

[ellemouton]

Gossip v1.5:

Plus one for Rusty's point re gossip 1.5. Some pre-reading here which also includes links to past mailing list posts about the topic. Some specific points that we should make a decision on:

• go all TLV or no
• to what degree do nodes want to prove a UTXO is bound to the LN context (if at all). Can we at least optionally make these more or less so?
• can we assume that dynamic commitments will be in place and therefore we dont need to worry about using the new gossip messages for legacy channels?

Dynamic commitments:

This proposal defines an upgrade path for updating some of the currently static parameters of a channel that are negotiated at open time such as max_htlc_value_in_flight_msat etc and also defines an upgrade path for updating to a different commitment type (ex: legacy anchor/non-anchor to simple taproot chans)
Some pre-reading available here

Simple Taproot Chans

Not sure if there are any more discussion points here or if all impls are happy with the current proposal. If the latter, then some interop testing at the meeting would be cool

(cc @Crypt-iQ & @Roasbeef )

[t-bast]

UTXO management for LSPs in a splicing world

Splicing is great for LSPs because we can now use only one channel per user. But the main regression that it creates is that change outputs on unconfirmed splice transactions are unsafe to use, whereas change outputs on funding transactions were safe to use (as long as you make sure you don't double-spend yourself).

This creates more pressure on the utxos of LSP wallets (when supporting on-the-fly splicing for HTLCs that cannot be forwarded because of a lack of incoming liquidity), which is particularly hard to manage when using the Bitcoin Core wallet, which doesn't have a way of fine-tuning coin selection to optimize for that kind of usage.

[carlaKC]

Going to send out a poll to gauge interest in various topics on Monday 12th, final reminder to add topics you're interested in!

[joostjager]

Inbound routing fees

Currently routing node operators price their routing service based on the used outbound channel only. This proposal seeks to add more control for operators by also allowing them to adjust their price depending on the inbound channel.

Specification: lightning/blips#18

We've talked about this proposal many times already in the spec meetings. I don't have specific questions at the moment, but putting it up anyway for that upcoming vote in case anyone wants to include it.

[joostjager]

In addition to the technical topics, maybe it could be interesting to have a time boxed discussion around a question such as "what's holding back lightning the most", "to what extent does lightning impact the world currently", "if lightning would die, what would be a likely cause of death" or some other softer type of statement?

EDIT: Or "what would happen if all dev teams fused into one" 😅

[rustyrussell]

Fast Failure and Nacks

There are two options which become interesting once we have a simplified (uniplex) update protocol.

The first is the old idea that we can "fast fail" HTLCs ("I know you haven't sent update_signed yet, but just FYI I'm going to fail this update_add_htlc like so"): combined with an update_unadd_htlc which allows you to remove the HTLC before update_signed (if you receive the fail msg in time).

The second idea is that it becomes feasible to "nack" changes (revoke_and_nack which commits to none of the changes, or at least, none of the adds). This is important, as it means you no longer have to tell the peer to limit the sats in flight etc, nor tell them about updates dynamically. You still want to go through a revoke-ack cycle, since the peer will want to send a new commitment_signed immediately so it is not committed to the HTLC. This combines obviously with the "fast fail" above: you should have failed at least one HTLC before sending revoke_and_nack.

[carlaKC]

Votes are in (mostly! missing 5 people)

Min/max normalized topic votes:

Summit Format:

Audio Recordings:

Per-topic interest distribution (ie, raw data for the normalized summary):

[carlaKC]

Edit: Discussed further in spec meeting, see below!

Given the above, I think that it could make sense to have full group discussions on the top few topics in the morning / early afternoon and then break up into smaller groups/unconference style in the late afternoon to get through the rest. Something like:

Wen Taproot Wednesday

• Taproot Channels
• Gossip v1.5 vs 2
• PTLCs

Troubles Thursday

• Channel Jamming
• (HTLCS handling in light of) High On Chain Fees
• Package Relay and related updates Breakout Group

Future Friday

• Blinded Paths
• Async Payments
• Meta Discussion

Going to put this on the agenda for the next spec meeting so we can chat about what's going to be the best use of time!

In the meantime, please keep adding items here (with any relevant resources) as they come up!

[renepickhardt]

Sorry for the late post but @carlaKC asked me to post this here as it would help everyone to prepare instead of surprising some folks.

I would like to use the meeting to propose the initiation of a "Reliable payments working group". The idea is to create a TCP style layer on top of the current LN (which currently with its onion routing from some point of view mimics UDP of the internet protocol suite). I have made a similar proposal last meeting where we have some context.

This Transport Layer (could eventually be a BOLT or LIP) should create peer 2 peer communication protocols that address the following goals:

1. Higher Payment reliability (e.g. guaranteed SLAs as originally described here and currently worked on here)
2. Congestion Control (for example channel jamming research)
3. Flow Control (for example via control valves but also via fees or fee rate cards)
4. Liquidity Management (Swaps & Rebalancing, Splicing, Liquidity ads, or Information Sharing)

With respect to this proposal I would give a short update on recent research results on planning redundant overpayments and bring a short impulse presentation laying out a potential roadmap for a reliable payments working group.

The idea for this group is - after we gathered experiences about payments and have some ideas to address the shortcoming - to find out what needs to happen on a spec level and what could rather stay on an application level. In particular we have seen that some proposals may not work together. So I'd like to start this group not with a particular goal or solution in mind but rather focus on the requirements so that we can figure out together what needs to be done in the future.

[carlaKC]

Few other things that didn't make the survey in time:

• Fee rate cards
• Covenants for LN
• Probing / Routing discoverability and success rate

[carlaKC]

Jess Jonas from the bitcoin legal defense fund will be in on Friday 30th at 11:30 for an optional Q&A.

[ariard]

Won't be with you all this year for the LN summit due to the organizers not knowing yet how to handle conflicts of interests in Bitcoin FOSS in a professional fashion.

That said, in light of proposed topics here few bullet question points to constructively feed the discussions:

• dynamic upgrade:
  • what is the level of conceptual separation we can achieve between policy parameters (e.g max_htlc_value_in_flight, csv delays) and channel types (taproot, eltoo) ?
  • do we need a negotiation mechanism if the matrix of safety/privacy/fee cost effectiveness does not bind with the latest rolled out channel types ?
  • do we need compatibility of channel structure with mempool to enable retro-activity of policy effect in case of safety emergency (e.g apply v3 on old channel types) ?
• onion jamming DoS:
  • what are the trade-offs of different strategies (rate-limiting based on slots, proof-of-work like tor, UTXO-based) ?
  • what are the economic interferences with the traffic relayed (e.g offers) and risks of indirect jamming attacks ?
  • what basic per-link bandwidth we'll have for the first version and do we encomass some basic rate failure ?
• package relay:
  • what should be the default of v3 package limits and the covered flows (commitment+HTLC broadcast, or cooperative/splicing/dual-funding) ?
  • what are the corner-cases of implementing package support in term of batching second-stage HTLC and shared CPFPs ?
  • what are the types of pinning attacks aimed to be covered by ancestor-based package relay (bip 331) and v3 ?
• channel jamming:
  • what are the economic and bandwidth trade-offs between jamming solutions: htlc endorsment, staking credentials, circuit breaker
  • how amonetary strategies could be re-used to mitigate future liquidity griefing ?
  • what will be the impact of jamming mitigation on payment reliability ?
• PTLCs:
  • what level of compatibility of proposed schemes with threshold schemes like FROST or any motonic access structure for DLC oracles ?
  • what is the path for network-wide deployements and can we have generic gossip mechanism to announce more custom/enhanced LN packets in the future ?
• legal issues:
  • in light of CSW lawsuits on the Core-side, do we have learnings on the griefs raised, namely fiduciary duties and database rights claims (EU law only for the latter) ?
  • in light of the Tornado Cash case, do we have learnings in term of privacy-preserving open-source technology ?
  • how the legal risks exposure for the Lightning community compared to the Bitcoin Core one ?
• gossips:
  • do we aim for a proof-of-ownership scheme compatible with other Bitcoin applications like coinjoins ?
  • can we integrate with things like utreexo to ease the UTXO access set burden for mobile nodes ?
  • do we know which performance/bandwidth trade-offs is the best default fit given Lightning communication requirements and what cryptosystems to pick up in consequence ?

Thanks for the transcripts - Will ease the followup work on my side to spot the technical weaknesses as usual in the proposals resulting from the summit !

[carlaKC]

Discussed format for the summit in today's spec meeting.

Full group discussions:

• Gossip v1.5 vs 2
• Simple Taproot Channels
• Channel Jamming
• Dynamic Commitments
• Meta Discussion (combined)

Structure:

• Mornings: Full group discussions
• Afternoon: Smaller Breakouts (unconference style)
• End of day: Optional wrap up where breakouts report back with quick summary of progress

[Crypt-iQ]

I'll update the dynamic commitments draft this week since the link above is outdated

[niftynei]

Things I'd like to talk about (that haven't been mentioned yet):

• closing fees: rate negotiation tactics, duplicate sig txs?, closing fee payment responsibility, interactive-tx for closes?, taproot + closing fees
• reserves: can we get rid of them?, reserves + splicing, game theory of closes (related to closing fees, penalties + eltoo)
• fee rate cards: ok ok already mentioned above, probably honestly needs more research before discussed again (afaiu status is relatively unchanged since last meeting a year ago)

[carlaKC]

Posting some resources that will be helpful if you’d like to catch up with the work that @ClaraShk and I have done on channel jamming.

If you’re looking for a quick catch up, tl;dr one page summaries of various topics:

• Overview of Solution Space
• Motivation for a hybrid solution
• Details of Local Reputation + HTLC Endorsement

If you’d like a deeper dive:

• Blog post summarizing solution (with original paper linked)
• Overview of Concepts (slideshow)
• WIP Endorsement BOLTs PR

We’d like to discuss the solution space and the details of local reputation + htlc endorsement at the summit.

[ariard]

About the "meta"-discussion (scheduled on Friday) I do have few bullet points in my mind:

• specification process
• cryptocurrencies devs legal risks
• next LN summit

On the specification process, the last time the advantages and downsides were discussed in depth was on the mailing list in June and July 2021 from a proposal by Ryan and Laolu. At the time, in face of a growing LN ecossytem, there was a discussion if a lightweigher version of the BOLT process could be followed without the historical rule of functional features compatibility between implementations. A lot of LN features were hacked in the wild like JIT channel, LN-URL or podcast payment metadata.

One of the outcome of the conversation to consider a separate process was iirc a) the lack of review resources by other LN devs and b) the risks of deliver specification sub-optimal in term of long-term privacy impacts and c) the safety risks of the state of Lightning infrastructure circa 2020/2021. During the Zurich LN summit where the 4 more-mature LN implementations were present (LDK, CLN, Eclair, LND), the subject was discussed more in depth and the blip process adopted (and we moved back to video calls for the biweekly meetings).

There was not real discussion on the specification process in a Oakland, to the best of my "oral" memory. Stil, few applications or LSPs projects were present (or invited).

Since then, the LN protocol development has become more specialized in subsystems: channel state machine, payment routing/scoring algorithms, on-chain monitoring and breaching logic, heuristic-driven automated liquidity engine, watchtower, automated fee risks management heuristics (and the architecture separation is quite similar across LDK, CLN, Eclair and LND) and protocol areas of concerns (channel jamming, package relay and anchor output, payment reliability, dynamic channel upgrade, taproot, consensus-based change like eltoo, musig2/frost, onions and offers).

Beyond it sounds there are few more developers and stakeholders involved in the Lightning development process hopefully making the careful review process of BOLT drafts and proposals far more smoother, than it used to be and lead to propose the BLIP as a new thing.

From a technical viewpoint, it sounds the Lightning protocol is expected to live more and more as a stack of separate protocols at the image of RFC 791,
RFC 792 (yeah no one knows ICMP though *Nix's ping/traceroute are based on it), RFC 4271, RFC 7230 e.g and this is was quite envisioned (cf.f Mastering Lightning’s lightning network architecture chap) by the "very-OG" crew of Milan 2016.

In the future, it sounds a better process can be to have dedicated Working Groups (and as it's suggested by Carla too),
quite like the IETF's ones are working. IMHO, we could have the following:

• "Reliable payments" WG: high payment reliability, congestion control, flow control, liquidity management (scope sounds good, nice if we can add mempool congestion cycles)
• maybe "Base-Layer Propagation" WG: fee-bumping reserves, go-to-chain heurisitcs, dynamic fee-bumping anchor outputs and nversion=3
• maybe "The Default & /dev/urandom" WG: taproot and new channel types or new packets like dlcs, dynamic upgrades, anything related to the "maintenance" of the protocols or that don't fit elsewhere
• maybe "The Apollo" WG: eltoo, covenants and long-term scalability things like joinpool/coinpools
• maybe "LSP/watchtowers/LaaS" WG: as it's more client-server architecture, most of time for clients on unreliable ressources the technical philosophy will probably converge

I think I'll advocate for the onions and any DoS mitigations strategies to stay in its own future working group process, as current large-scale privacy-enhancing network like Tor, though here if it starts to be more cryptography heavily, good to have few libsecp256k1 folks joining.

I don't know if it sounds too much formal though I think it can be okay to have named WG "chairs", where few people are designated to ensure progress are being made on a "running code" fashion. Still, I think it would be good to have each WG "chairs" being co-shared with one or two "shadow” chairs from another Lightning implementation to safe-guard procedural neutrality between implementations and be sure you have good functional compatibility, if possible with a testing framework like lnprototest used to be.

Each "BOLT" document could have a header explicitly assigning to one of the WG group like we're doing for bips
("consensus"/"p2p"/"applications") and we can even have new GH repositories to keep janitorial permissions small
(waiting we move on something decentralized like Nostr, soon(tm)).

[ariard]

On the legal issues, I think the ongoing litigations faced by some Bitcoin Core devs have insights.

To the best of my knowledge, there are 2 legal actions opened by CSW against a bunch of defendants. On the database rights case, the claim is based on the Copyright and Rights in Databases Regulations of 1997 which implements into UK law provisions from EU Directive 96/9/EC (yeah the european legislation have always hard to remember number rather than clear names like member states). It introduces a sui generis property right to the maker of a "database", where the factual criterias are a) initiative in making the database and b) doing substantial and risk-exposed investment in the making-process of this database. Note, there is no strict equivalent of the database rights under the US federal law, minding judicial decisions on "copyright" though there is a clear element of creativity required by US courts.

The database rights case is weak. First, the Database Rights apply only to members of the European Union, of which Australia is not part of. CSW is known to have been a resident of Australia at that time, and unless CSW can prove sustained centers of interest which have been leveraged for the claimed original development of Bitcoin before the project started to be publicly managed by a set of contributors like Wlad, Gavin or Sirius, after version 0.3.9, the database rights just does not exist under Australia law.

Second, there is a clear criteria raised by the UK laws on the notion of "risk investment” which should be understood again as a substantial or material risk beared by the database maker to claim the "first ownership" of the database right. The Bitcoin whitepaper gaves at the very least a clear technical definition of the making-process of the blockchain. The genesis block had no “financial" costs, all the subsequent blocks have energy costs (even minimal given the difficulty at that time) attached and CSW should be able to cryptographically prove both owning the coinbase pubkey for each block he claims to have made substantial investment in and the electricity bills (as he could have just proposed block templates to real miners and hijack the pow ownership, same way than mining pools). In the lack of such legal proofs there is no way a "sui generis" right can be valid. There is no doubt "electronic signatures" have a legal validity under EU laws (and mind the notion of "sui
generis', if you have PhD-level in property law from the greco-roman tradition).

Thirdly, the database rights litigation is done in the UK court on the ground of an EU directive. Post-Brexit, there is legal uncertainty on the validity and enforcement of such rights beyond the UK jurisdiction. There is a period of 15 years of protection for the database rights, given than Bitcoin has been released in January 2009, the validity of the right of the database will expire in 2024. As the extension of the dabatase protection right is based on the necessity to keep doing substantial changes, CSW would have to prove he produces 51% of today hashrate to maintain the database right. Again, note the sui generis character of the right.

Fourthly, if the database has been made jointly by two or more persons acting together in collaboration the "maker" right is shared. Given than the Bitcoin whitepaper quotes among other the work of Wei Dai (public announcement of transactions as the making process of the blocks), Suhas Haber (chain of timestamps) or Adam Back (hashcash), there is legal uncertainty if the database right can be really exercised without their consent, or any corporation that might have funded their intellectual works.

The Tulip Trading Case is different has here CSW is claiming a fiduaciry duties on few Bitcoin Core devs. Under UK's Mothew, a "fiduciary duty is someone who has undertaken to act for or on behalf of another in a particular matter in circumstances which gives rise to a relationship of trust and confidence. The distinguishing obligation of a fiduciary is the obligation of loyalty".

Same than database rights, I think the case is still fundamentally flawed. The factual test to qualify a fact-based fiduciary duty are the following criterias a) an undertaking to act on behalf of or for another person, b) a discretion or power to act which affects the interest of that other person and c) the peculiar vulnerability of that person.

The first criteria is explicitly ruled out by the MIT license and its generic discharge of warranties or liabilities as the "undertaking to act" is clearly rejected by the act of attaching the MIT license on Bitcoin reference client code since its original publication in 2009.

The second criteria does not apply either as CSW has always the technical ability to run a fork of Bitcoin Core, or not even upgrade its current node (if he's understanding correctly the bitcoin security model to protect the allegued coins with the addresses mentioned in the litigation documents). There is no economic damage than Bitcoin Core devs might provoke by a deliberate targeting of CSW's coins as consensus rules cannot be upgraded without the majority of hashrate, of which most of the part is controlled by "public" mining pools not being connected with devs, beyond the necessity of compatible softwares. And if there is a historical outcome of the block size wars, there is no material influence of Bitcoin development protocol community to change consensus rules, beyond the scientific process of softfork activation, where each upgrade is unique in itself, in the same sense than updating the CEDH or the US constitution itself is unique.

The "private" cryptographic ownership of the allegued coins is respected, and in fact any non-consensual modification of the consensus rules would damage the "economic value", which if the fiduciary duty does exist (of which I deny the complete ground of it) could be a breach of the fiduciary duty itself as the notion of loyalty might allow you to take protective against the legitimate owner of the "asset" (here again mind the notion of "loyalty" if you have PhD-level in trust and patrimonial law from the greco-roman tradition).

The third criteria does not apply as if CSW is the cryptographic expert he claims to be he does have level-playing knowledge and skills with the usual contributors to the Bitcoin Core project. Therefore, there is no material asymmetry that can qualify as a "peculiar vulnerability".

That's for the "legacy" CSW cases and the legal analysis is mostly oriented base-layer. Still I think it can be valuable to understand well the CSW cases, as we’ll have cross-layer interdependency between both, including on the legal field.

Lightning is a far more novel architecture. Though here, it is expected Lightning developers open-source works
to be protected by the fundamental texts either in the US (e.g the 1st Amendment) or in the EU jurisdictions Article 10 of the CEDH, with the enhanced protection than scientific and research works are beneficing from (though here note the difference between US and EU on the fundamental rights protected).

There is still an observation than due to the technical architecture of Lightning, the regulatory oversight will be not the same than for Bitcoin nodes. Here I invite to think about current practices done by VPN. Note there is a strong legal difference between running a "hobbyist" Lightning node and a commercial Lightning node with active promotion in term of “customer" data handling (and here that's quite an invariant between US and EU law systems).

Being a dropout of the top European contentinal law school, I'll keep sharing relevant legal information with the BLDF and see what I can do to have more legal experts in Europe familiar with the unique technical nature of Bitcoin, for the benefit of everyone in the Bitcoin protocol development community.

Disclaimer - This is legal information only and not advices, ask more to your respective legal teams.

[ariard]

And finally, I'm proposing myself to organize next year LN Summit in Africa, probably in June 2024.

I have the contacts in the English and French-speaking Bitcoin communities and for the operations I do have the experience of co-organizing the Zurich LN and CoreDev event back in 2021, in the heart of the pandemie volatility.

One lesson from Zurich, good if the operational todos (country, location, final dates, travel visas if needed) are fulfilled as early as we can for everyone visibility. Of course, for that type of events there is the concern of confidentiality, while still having good accountability towards attendees, so looking to have multiple co-organizers and a multi-stakeholder approach. There is always the risk of a new wawe of pandemie where there can be time-sensitive trade-offs to weigh and a quasi-unilateral decision being made with hazardous outcome as somehow I did happen with the first-in-Biarritz-then-in-Zurich event back in 2021, though that should be okay.

I'll be very careful in the management of potential conflict of interests and bind to best ethical open-source standard during the organization, if during this Friday there is time to collect feedbacks on the list of countries (Algeria, Ghana, Nigeria, ...) with acceptable operational trade-offs, that would be very welcome.

I'll do an announcement on the mailing list and for people who wanna contribute to the organization, please reached out to: lnsummit2024@ariard.me (active Lightning development contributions required, thanks).