Scaling Lightning With Simple Covenants [combined summary]

• Scaling Lightning With Simple Covenants jlspc 2023-09-28 22:40:05+00:00
• Scaling Lightning With Simple Covenants jlspc 2023-09-28 15:56:11+00:00
• Scaling Lightning With Simple Covenants Antoine Riard 2023-09-26 16:42:34+00:00
• Scaling Lightning With Simple Covenants David A. Harding 2023-09-24 21:40:29+00:00
• Scaling Lightning With Simple Covenants ZmnSCPxj 2023-09-19 07:44:48+00:00
• Scaling Lightning With Simple Covenants ZmnSCPxj 2023-09-18 04:14:55+00:00
• Scaling Lightning With Simple Covenants Erik Aronesty 2023-09-17 11:32:52+00:00
• Scaling Lightning With Simple Covenants jlspc 2023-09-17 00:59:39+00:00
• Scaling Lightning With Simple Covenants jlspc 2023-09-17 00:56:04+00:00
• Scaling Lightning With Simple Covenants jlspc 2023-09-17 00:52:13+00:00
• Scaling Lightning With Simple Covenants Antoine Riard 2023-09-11 05:27:25+00:00
• Scaling Lightning With Simple Covenants Rusty Russell 2023-09-11 02:13:52+00:00
• Scaling Lightning With Simple Covenants Anthony Towns 2023-09-11 00:56:40+00:00
• Scaling Lightning With Simple Covenants jlspc 2023-09-08 18:54:46+00:00

Published on: 2023-09-28T22:40:05+00:00

Summary:

The email discusses a proposal regarding the scalability and trust-free nature of the Lightning Network. It raises concerns about the cost implications and expected fees contributed by the "dedicated user", as well as the potential penalties in case of failure by either the dedicated user or the casual user. The email suggests relying on legal and custody policies instead of burdening the UTXO set indefinitely. It explains the tradeoff between trust and capital efficiency in the context of a single UTXO claimable by "B" at a specific time, and highlights the "thundering herd" problem that arises if B cheats. The email proposes solutions such as calculating extra transactions generated in the worst-case scenario and rollover funds accordingly. It also explores challenges related to reducing the inactive lifetime (LI) timeout for casual users and the impact of collusion among different providers. The email suggests peering with a dedicated node, varying timeouts at different layers, and considering idle balances as possible solutions. The scalability problem of providing Lightning channels to casual users is addressed, along with limitations of signature-based factories and the use of simple covenants. Timeout-trees are proposed as a long-term scaling solution. The email also discusses the availability problem when draining funds from an old timeout-tree to a new one and suggests using a variation of the FFO-WF Lightning channel protocol. In conclusion, the email argues that implementing simple covenants and timeout-trees can improve the scalability of the Lightning Network for payments, while acknowledging limitations and expressing hope for the addition of mechanisms like CheckTemplateVerify (CTV) or AnyPrevOut (APO) to Bitcoin's consensus rules.

Updated on: 2023-09-30T01:51:46.364674+00:00