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: Attributable failures 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" 😅