bitcoin-dev

Scaling Lightning With Simple Covenants

Scaling Lightning With Simple Covenants

Original Postby Antoine Riard

Posted on: September 26, 2023 16:42 UTC

In the email, Antoine discusses various aspects of off-chain constructions and their efficiency considerations.

He mentions that transactional scaling of Lightning, which refers to how many transfers can be performed off-chain per on-chain transaction, may face liquidity unbalance due to asymmetries in liquidity flows among counterparties. However, he notes that on-chain splicing for LSP spec upgrade improves this dimension by allowing resizing or pool rebalancing.Antoine also addresses the challenge of getting a million casual users to sign a transaction, stating that pre-committing a subset of casual or inactive users is not straightforward. He suggests the use of efficient cryptographic accumulators at the consensus level for scalability.Regarding timeout-trees and channel resizing, Antoine points out that they suffer from the lack of fault-tolerance when a casual user or end of tree balance owner wants to go on-chain. The fragmentation cost is borne by all the users located in the tree branch. He emphasizes that fault-tolerance is a key design goal for payment pool advancements over factories.Addressing the issue of performing actions within a limited time window, Antoine acknowledges that most off-chain constructions require strong liveliness and highlights TP-channel factories' novel aspect of allowing casual users to decide when they need to be on-time.The email also mentions the "thundering herd" problem, which is explicitly mentioned in the OG Lightning paper. Antoine states that this problem cannot be fixed by transaction-relay changes and needs separate considerations.Furthermore, Antoine discusses failures by dedicated users who can afford highly-available hardware and maintain a good reputation. He notes that once a dedicated user has many off-chain trees, they become an attack target, altering the trade-offs.Additionally, Antoine refers to the concept of "cut-through" to reduce on-chain footprint in mass exit cases. This concept has been discussed since the early days of off-chain constructions and is related to Taproot and Grafroot introduction.Finally, Antoine poses a couple of questions about the TP protocol's security model in scenarios involving multiple parties and commitment transactions. Specifically, he asks about preventing collusion and double-spending to protect the interests of all parties involved.Overall, Antoine's email covers various aspects of off-chain constructions, including scalability, fault-tolerance, liveliness, and security considerations.