Author: Michael Folkson 2022-06-21 11:54:27
Published on: 2022-06-21T11:54:27+00:00
Recently, a Lightning Network Developer Meeting was held in Oakland, California, where nearly 30 developers and researchers gathered for three days to discuss various topics related to the Lightning Network. One of the main discussions was about nonce handling, which requires a new set of nonces every time a signature is re-transmitted. Attendees also discussed leveraging recursive MuSig2 to make channels more multi-sig, allowing node operators, wallets, and lightning platforms to experiment with various key/signing trees that may add more security, redundancy, or flexibility.Another topic discussed was the update of the gossip network for Taproot. A proposal for redesigning the entire gossip protocol with an eye for better privacy and future extensibility was presented. However, it was decided to take just the MuSig2 aspects from Gossip v1.5 and refresh all messages with TLV goodness from Gossip v2 proposal for implementation. The meeting also covered other topics like applying Mini Sketch to LN Gossip, channel jamming, and DoS concerns related to onion messages.During the Lightning Network developer meeting, attendees discussed various proposals, including rate limiting or pricing resource consumption to prevent DoS attacks, using blinded paths to increase privacy for LN users, and friend-of-a-friend balance sharing to potentially increase payment reliability. Other proposals discussed include implementing Eltoo and ANYPREVOUT, as well as trampoline routing as a solution for mobile users who do not want to sync the entire graph. Some proposals are close to deployment, but more work needs to be done to concretely specify and properly analyze them.The Lightning Network developer meeting also discussed several proposals involving Use case #2 with holding Hashed Time-Locked Contracts (HTLCs) at an origin node, which could allow for a more asynchronous user experience. Trampoline can also be combined well with blinded routes and Multi-Path Payments (MPP). However, senders may need to overshoot fees and CTLVs until more data is collected on how much extra needs to be allocated. Another proposal involves allowing nodes to express a fee gradient via a static curve/bucket/function, rather than dynamically communicating the latest state of the fee+liquidity distribution.Splicing was also discussed, building off the interactive-tx scheme that the dual-funding protocol extension uses. The main question is whether concurrent splices should be allowed and, if so, how to handle edge cases. Wallets would likely show the most pessimistic value for a user's Lightning balance. LN-URL and BOLT 12 are both standardized ways of obtaining Lightning Network invoices. Both proposals can be combined, leading to all wallets and implementations being able to decode and send with a BOLT 12 invoice.
Updated on: 2023-06-03T09:02:50.705837+00:00