search

lightning / bolts

BOLT: Basis of Lightning Technology (Lightning Network Specifications)
2.06k stars 490 forks source link

Lightning Dev Summit Topics #1078

Closed carlaKC closed 11 months ago

carlaKC commented 1 year ago

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:

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

vincenzopalazzo commented 1 year ago

I would like to have a discussion on the trampoline https://github.com/lightning/bolts/pull/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 commented 1 year ago

Splicing

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

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:

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:

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 commented 1 year ago

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:

valentinewallace commented 1 year ago

Async Payments

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

Initial spec PR: https://github.com/lightning/bolts/pull/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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago
  1. simplified commitment https://github.com/lightning/bolts/pull/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 commented 1 year ago

  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 commented 1 year ago

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:

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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: https://github.com/lightning/blips/pull/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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

Votes are in (mostly! missing 5 people)

Min/max normalized topic votes:

Screenshot 2023-06-15 at 9 41 43 AM

Summit Format: Discussion Format

Audio Recordings:

Screenshot 2023-06-15 at 9 41 10 AM

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

carlaKC commented 1 year ago

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

Troubles Thursday

Future Friday

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 commented 1 year ago

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 commented 1 year ago

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

carlaKC commented 1 year ago

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

ariard commented 1 year ago

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:

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 commented 1 year ago

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

Full group discussions:

Structure:

Crypt-iQ commented 1 year ago

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

niftynei commented 1 year ago

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

carlaKC commented 1 year ago

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:

If you’d like a deeper dive:

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

ariard commented 1 year ago

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

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:

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 commented 1 year ago

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 commented 1 year ago

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).