lightning-dev

Scaling Lightning With Simple Covenants

Scaling Lightning With Simple Covenants

Original Postby Antoine Riard

Posted on: September 11, 2023 05:27 UTC

In the email, Antoine provides feedback on a proposal regarding the classification of users and the design of protocols.

He points out that classifying users as "casual" or "dedicated" may not be straightforward, as trust assumptions in practice can be more nuanced. He gives examples of choices that users have in terms of block-relay, mempool size, routing HTLCs, and running local watchtowers. Antoine suggests that different scaling notions can be introduced to measure the performance of an off-chain construction, such as onboarding scaling, transactional scaling, and users resource scaling.Antoine mentions that the proposal mainly focuses on onboarding scalability, which involves maximizing the number of channels owned by a user. However, it is unclear if other scalability dimensions are taken into account. He questions the accuracy of a statement that no known protocol allows a large number of Lightning channels to be created from a single on-chain UTXO. He provides a link to a discussion on Bitcoin-dev mailing list that proposes a solution using a radixpool with Musig2.Antoine highlights the difficulty of coordinating a group of casual users to sign transactions specifying the exact set of users required. He identifies two specific problems related to group coordination: adding/removing users in a compact fashion and updating the channels owned by the users with minimal interactivity. He also raises concerns about the uncertainty of draining funds in a network where jamming is possible and the role of dedicated users in routing.Antoine points out that the requirement for casual users to perform actions at specific times in the future may be altered by the fact that there is no guarantee of timely on-chain transactions. He also mentions the potential challenges of immediately-accessible pre-signed/pre-committed transactions not propagating on the network due to mempool minimum fees.Finally, Antoine expresses uncertainty about the fault-tolerance of the off-chain construction, particularly if a user becomes unresponsive after a while, which could result in the entire construction being moved on-chain.Overall, Antoine provides detailed feedback and raises several important considerations regarding the proposal's classification of users, scalability dimensions, group coordination, routing challenges, and fault-tolerance.