Published on: 2022-06-30T16:38:37+00:00
During a recent email exchange, Bitcoin developer Peter Todd suggested the idea of allowing users to opt-in for slower payment processing for increased privacy. This could be beneficial for rebalancing and other automated processes. While it may not be practical to hold onto a hashed time-locked contract (HTLC) for too long, waiting a second instead of 100ms to batch transactions could still provide benefits without creating capacity issues. Some in the Bitcoin community find this idea interesting.In the discussion about the Lightning Network (LN) protocol's latency sensitivity, Christian Decker mentioned that slow signers should not cause too many issues, except for slower forwards in the case of routing nodes. However, if forwarding nodes take a full second to forward a payment, it may be necessary to avoid such nodes. Matt Corallo suggested that a good goal would be to get 95th percentile payments down to one second to avoid retrying payments. Implementing a timeout on the peer level is not recommended, but it may need to be handled in route selection if it becomes more of an issue going forward.Christian Decker also mentioned that the LN protocol is generally not very latency sensitive and can handle slow signers without causing too many issues. Routing node signers are expected to be well below the 1-second mark, even when implementing more complex signer logic. The LN protocol implements a batch mechanism where changes are applied to the commitment transaction as a batch, so while a slow signer may impact payment latency, it should not affect throughput on the routing nodes.In a Lightning Network developer meeting, several proposals were discussed, including nonce handling, leveraging recursive MuSig2 for multi-sig channels, updating the gossip network for Taproot, applying Mini Sketch to LN Gossip, and addressing DoS concerns related to onion messages. The meeting also covered topics like rate limiting, privacy enhancement, and increasing payment reliability. Some proposals are close to deployment, but more work needs to be done to specify and analyze them properly.During the meeting, attendees discussed the use of nested or recursive MuSig2 for threshold signatures. The terminology "nested MuSig2" was chosen for simplicity. There was also discussion about the latency impact of adding more signers in the multi-signature setting for LN. The LN protocol currently does not verify Schnorr signatures, but the plan is to use musig2 in the funding output for a single aggregated key. Some added latency may occur depending on the system architecture.Another proposal discussed at the meeting was splicing, which builds off the interactive-tx scheme used in the dual-funding protocol extension. The main question was whether concurrent splices should be allowed and how to handle edge cases. The meeting also explored the topics of LN-URL and BOLT 12 as standardized ways of obtaining Lightning Network invoices.In another discussion, Bastien expressed skepticism about a proposal for rate-limiting, stating that it does not provide enough protection against private gossip. ZmnSCPxj shared waxwing's proposal for a proof-of-channel-ownership mechanism that matches the requirements for lightning gossip, but emphasizes the need for a global network to prevent UTXOs from being reused across services.At the LN Dev Summit, Taproot updates were a major topic of discussion. Taproot has now been fully activated, and progressive revamping of the system using more taprooty features was proposed. Other discussions at the summit included applying Mini Sketch to LN Protocol, evaluating channel jamming solutions, addressing last-mile privacy issues, and optimizing node fees. The importance of invoice fetching in light of blinded paths was also discussed, with LN-URL and BOLT 12 being two standardized methods for fetching invoices.Overall, the Lightning Network community is actively exploring various proposals to improve the protocol's efficiency, privacy, and reliability. Discussions range from latency sensitivity to rate limiting, payment optimization, and the implementation of new features like Taproot. These discussions aim to address the challenges faced by the Lightning Network and enhance its functionality for users.During the meeting, various topics were debated and discussed, with a particular focus on wallets and implementations. It was noted that these entities would benefit from displaying the most pessimistic value. The meeting yielded several interesting developments, underscoring the need for further research to provide better guidance regarding best practices in this domain.
Updated on: 2023-08-01T00:32:52.266538+00:00