Lightning Dev Summit Topics

[t-bast]

I'm creating this issue to track topics people are interested in discussing during the upcoming lightning dev summit.

Feel free to add topics that you'd like to see discussed and (light) reading material related to it: we don't expect participants to spend a lot of time preparing before-hand (we all have a lot of work to do already), but it can be useful to guide people who do have some time to prepare, or casual readers of this issue.

Note that the topics aren't ordered at all, don't let that bother you! There's no universally best order here since everyone has different priorities for the network.

Topics

Route blinding

Route blinding is an important prerequisite for many things that people are working on (onion messages, bolt 12, better payment privacy, ...). It's highly non-trivial and deserves more review to make sure we didn't miss anything. In particular, blinded payments make some opinionated choices (which may or may not be the best choices), so they would greatly benefit from more review!

The PR contains a high-level document with explanations and example: #765

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 will make a presentation during the dev summit: it is much easier to understand and reason about while visualizing some sample graphs and paths within those graphs. I will share this presentation before the meeting for those interested (once it's ready).

Splicing

Splicing is great. We should do it. It was in the list of upcoming features proposed in 2018 in Adelaide (it was even proposed to use feature bit 12 for it, how far we've come since then!).

There is a large design space around splicing and it will be useful to explore it together.

Onion messages

Onion messages is making good progress in multiple implementations; the main criticism has been about rate-limiting. We've floated ideas for rate-limiting schemes that are able to go back to the source of spam (which we cannot easily do with HTLCs), it would be useful to detail them more.

Bolt 12: Offers

People are getting frustrated that they still cannot get a tattoo with their bolt 12 offer on it because of the risk of breaking changes.
We should discuss this for the sake of everyone who loves lightning and tattoos.

Offline Receive

A concrete proposal is available to only lock liquidity in the sender's channel, with the help of LSPs and onion messages: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003307.html

It's a good opportunity to also brainstorm a way forward for better offline receiving mechanisms.

Taproot! Taproot! Taproot!

I've put up a high-level summary of taproot changes here: https://github.com/t-bast/lightning-docs/blob/master/taproot-updates.md
We can very likely do better and go further, I'm happy to see how far @Roasbeef and @guggero have taken this since last fall.

[t-bast]

@rustyrussell @cdecker @niftynei @TheBlueMatt @moneyball @Roasbeef @guggero @ellemouton @renepickhardt please add topics of interest to you whenever you have time!

[TheBlueMatt]

The shutdown async PR list should be resolved as well.

[Roasbeef]

Does anyone have a link to the gist we used last time to collect topics? May be useful to reflect back on what was discussed last time, and the more meta items that were unresolved.

[TheBlueMatt]

Oh may also be useful to go over the offline-receive-signaling-via-onion-messages proposal from https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003307.html we could make even make progress on some of the more trivial bits of it if its the way forward on offline-"receive"

[vincenzopalazzo]

Due to the addition of probabilistic pathfinding on almost all the lightning implementation, I would like to propose also me research to collect and maybe standardize open lightning network metrics about nodes https://github.com/LNOpenMetrics/lnmetrics.rfc

This can be useful to improve the scoring of one node in the graph!

[t-bast]

Does anyone have a link to the gist we used last time to collect topics? May be useful to reflect back on what was discussed last time, and the more meta items that were unresolved.

It's here, it was a google doc you shared: https://docs.google.com/document/d/1fPyjIUNkc9W1DPyMQ81isiv1fKDW9n7b0H6sObQ-QfU/edit

I'll spend some time going through this to see what we've made progress on.

[moneyball]

Thank you @t-bast for creating this! Here are additional topics we might wish to cover (in no particular order).

• Multi-sig scripts for LN (as "simple" as FROST + taproot/Schnorr support?)
• APO/Eltoo
• Dual-funded channels
• Channel jamming mitigation https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003314.html
• Importance and relevance of the spec process, BOLT vs. BLIP
• Gossip "v2" https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003470.html
• Secure remote signing https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-May/003579.html

[moneyball]

@ZmnSCPxj any of your lightning-dev posts/ideas/topics from the past several years that you'd want to discuss?

[Roasbeef]

Found the old gist: https://gist.github.com/t-bast/ce6703ec3e896207309dd6b5ea89d98e

[moneyball]

• 0conf

[ZmnSCPxj]

This failure mode of the network (not sure if this has a name):

• Payment is routed A->B->C->D->E->F while onchain fees are rising.
• E shuts down for no good reason while D->E is inflight.
• D->E HTLC times out before E can come back online.
• D force-closes D-E channel to time out the D->E HTLC. Unfortunately due to rising onchain fees, it cannot confirm.
• D holds on to C->D HTLC, because until D->E HTLC can be confirmed timed out, in theory it can still claimed via the hashlock branch.
  • I believe some node software immediately fails the incoming HTLC, but that is attackable if C and E are sybils and E is only pretending to be offline.
• Onchain fees are so bad, D->E HTLC is still not confirmed when C->D times out.
• C force-closes C-D channel to time out the C->D HTLC, exacerbating the rising onchain fees.
• Goes all the way back to A->B.
• E may be involved in more than one payment routing attempt, meaning its unfortunate downtime compounds across all of them, greatly affecting the network.

Presumably anchor commitments help fix this by allowing D to panic when C->D timeout is approaching, letting D force more fees onchain before C->D timeout exacerbates the onchain feerates?

---

• Multi-sig scripts for LN (as "simple" as FROST + taproot/Schnorr support?)

Is this related to my nodelets idea?

---

Channel factories

---

Multipath-focused pathfinding algorithms

[renepickhardt]

I had a few conversations with people out of band over the last couple weeks that I would love to revive / rewrite the BOLT14 proposal (#780) to add more functionalities to the protocol that make the lightning network more reliable. If you ask me personally the low reliability is currently one of the largest pain points. So if I make a comparison with the Internet Protocol Suite We can see the following analogy which may or may not be a bit drastic

I am still not entirely sure if we need a standalone reliability BOLT 14 or if we should just work towards adding reliability features at the positions of our living document where they are but it is my feeling if we already extend functionality we can try to break up the heavily entanglement so I am leaning a bit towards a separate reliability BOLT. Things that may be included:

Topics of a Reliability BOLT (14)

Stuckless Payments

I think the main proposal is at: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-June/002029.html

Local Information sharing about liquidity

an outdated version with an initial proposal is at: #780 with some sample code at: https://github.com/renepickhardt/plugins/tree/balancesharing-plugin/balancesharing. I think it is worthwhile to mention that the our simulation framework for optimally reliable payment flows can easily simulate how our service level agreements improve given how how many bits of information we know from a set of channels. The two relevant API calls can be found at:

• activate_network_wide_uncertainty_reduction(self, n, oracle: OracleLightningNetwork)
• activate_foaf_uncertainty_reduction(self, src, dest)

I hope to bring some diagrams to the meeting that are more quantifiable but I am happy if anyone wants to already play around with it.

Disclaimer I know some people belief this can be done by indirectly signaling via fees. While this may be true I think gossip currently may be a limiting factor as channel_updates are currently not propagated too often to prevent gossip spam.

Ability to have redundant over payments:

As mentioned on the mailing list in this post I think the following two papers may be relevant:

• https://berkeley-defi.github.io/assets/material/1910.01834.pdf
• https://dl.acm.org/doi/10.1145/3479722.3480997

Latency

Latency is rather big pain point and may belong to the broader field of reliablity. Low hanging fruits (which can partially happen out of the BOLTs) are changing the path finding optimization objective to include latency or geo / ip distance based features as suggested (at the end of the linked comment) to @TheBlueMatt in the ldk issue and as noted in my own repo. There is also a summer of bitcoin project working on this.

Protocol relevant discussion:

For this we may wish to include local channel latency (or IP/geo distance) to gossip (though this could obviously be gamed)

Another source that is more protocol level if we start working on eltoo ideas as I belief the channel statement machine will need fewer roundtrips.

Intersection with existing topics

I did not name some of the topics that have already been mentioned that may or may not have an intersection with such a reliability BOLT

• channel jamming
• PTLCs
• potentially eltoo (though it should be to some degree independent)
• gossip v2 / gossip in general / Lightning messages (some information bay not be gossiped globally)
• Offline receiving

[ariard]

Few other topics in mind :

• watchtowers infra specs : https://github.com/sr-gi/bolt13/blob/master/13-watchtowers.md
• fee-bumping new primitives : transaction sponsors / sighash_group
• package relay / replace-by-something-do-know-yet-but-we-assume-it-solves-pinning / mempools
• payment pools
• new packets types (e.g DLCs/ Miniscript parseable packets)
• massive channel closures and network mempools critical congestion

[moneyball]

Multi-sig scripts for LN (as "simple" as FROST + taproot/Schnorr support?)
Is this related to my nodelets idea?

I just mean being able to use a multi-sig wallet (such as 2-of-3) for a LN channel. Let's say you and I have a channel together. And I want to use my 2-of-3 wallet to sign LN channel updates.

[manreo]

Is there a summary of the meeting? How was it? @t-bast

[tnull]

Is there a summary of the meeting? How was it? @t-bast

@Roasbeef posted a great writeup to the mailing list yesterday: https://www.mail-archive.com/[email protected]/msg02852.html

Meeting notes can be found here:
https://docs.google.com/document/d/1KHocBjlvg-XOFH5oG_HwWdvNBIvQgxwAok3ZQ6bnCW0/edit?usp=sharing

[manreo]

Thanks a lot