search

lightning / bolts

BOLT: Basis of Lightning Technology (Lightning Network Specifications)
2.08k stars 493 forks source link

Lightning Dev Summit Topics #987

Closed t-bast closed 2 years ago

t-bast commented 2 years ago

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: https://github.com/lightning/bolts/pull/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:

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 commented 2 years ago

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

TheBlueMatt commented 2 years ago

The shutdown async PR list should be resolved as well.

Roasbeef commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

moneyball commented 2 years ago

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

Roasbeef commented 2 years ago

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

moneyball commented 2 years ago
ZmnSCPxj commented 2 years ago

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

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 commented 2 years ago

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

Thumbnails (40)

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: https://github.com/lightning/bolts/pull/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:

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:

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

ariard commented 2 years ago

Few other topics in mind :

moneyball commented 2 years ago

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 commented 2 years ago

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

tnull commented 2 years ago

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/lightning-dev@lists.linuxfoundation.org/msg02852.html

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

manreo commented 2 years ago

Thanks a lot