lightning-dev

Scaling Lightning With Simple Covenants

Scaling Lightning With Simple Covenants

Posted on: October 6, 2023 16:26 UTC

In the email, John discusses various aspects related to Lightning network and channel resizing.

He mentions that hierarchical channels allow for the use of HTLCs to send Lightning channel capacity over the Lightning network. This enables channel resizing off-chain between channels that are not in the same pool.

John also brings up the issue of fragmentation costs imposed by a casual user going on-chain in the case of a timeout-tree. He suggests that the casual user should pay the funder for the fragmentation costs. To address this problem, he proposes requiring casual users to reveal secrets (hash preimages) that only they know in order to put timeout-tree transactions on-chain. Additionally, he suggests adding a fee-penalty output to each leaf transaction that pays from the casual user to the funding user, depending on which timeout-tree transactions the casual user put on-chain.

Furthermore, John introduces the concept of passive rollovers as a solution to eliminate the risk of HTLC-withholding attacks. Passive rollovers do not require the use of the Lightning network and completely eliminate this risk. He adds this advantage of passive rollovers in the latest version of the paper.

John also mentions a proposal for addressing the logarithmic blow-up of putting a control transaction defined by a covenant tree on-chain. He refers to "short-cut" transactions, which are described in Section 5.4 and pictured in Figure 14 of the revised version of the paper. These transactions provide a specific proposal for addressing this issue.

Additionally, John addresses the concern of mass exit cases and the need to reduce the on-chain footprint. While he acknowledges that cutting through to reduce the on-chain footprint is listed as an open problem, he doesn't find any specific solutions in the reference provided. He clarifies that the "short-cut" transactions he mentioned earlier are distinct from proposals for addressing mass exit cases.

In terms of security, John highlights that there are no cases where multiple commitment transactions can spend an output from the same state transaction. Each user's State transaction can only be spent by the same user's Commitment transaction, and each Commitment transaction requires signatures from all users in order to spend the value output from the Funding transaction.

In conclusion, John provides detailed insights into hierarchical channels, channel resizing, fragmentation costs, passive rollovers, addressing mass exit cases, and the security of commitment transactions. He also expresses gratitude for the recipient's deep-dive into these protocols.