Author: Antoine Riard 2022-12-13 01:55:43
Published on: 2022-12-13T01:55:43+00:00
Antoine and Greg are discussing the eltoo payment channel construction using V3+ephemeral anchors, which disallows batched bumps. Antoine raises a concern about an attack case involving a chain of old states broadcast by the cheating counterparty up to the mempool's `limitancestorcount`. However, Greg assures that the architecture doesn't suffer from 2*self_delay, and each transition aside from Slow/Settle/SX.y has no relative timelock so that relative timelock is all that matters.The watchtower cycle ends up looking more like the update phase of vanilla eltoo. They discuss several advantages of the eltoo construction, including limiting the publication of eltoo states more than once by a counterparty, strict bounds on shared_delay encumbered in the on-chain publication of the channel, and reducing latency of HTLC propagation across payment paths. They also talk about concerns such as doubled delays and penalties for cheating. There has been a proposal in the past to enable penalties on top of symmetric states by leveraging asymmetric witnesses. They also consider the possibility of a watchtower holding onto obsolete states and colluding with an attacker to attempt to cheat them.In the Lightning Network ecosystem, there are issues with watchtower designs and the execution of the protocol, leading to delays in claiming funds. A "simple and working" approach may be necessary for the current state of the LN ecosystem to enable faster transaction cycles and learning. Proposed solutions include adapting CTV-like approaches or using SINGLE/ANYONECANPAY signatures to add fees, as well as introducing more efficient fee-bumping primitives. From a security perspective, offsetting cltv_expiry_delta to a value higher than to_self_delay could be considered an improvement, but this may not align with long-term LN network incentives. The coordination of multiparty state updates is complex, but feasible with modern consensus algorithms. The Lightning Network is a two-party channel that allows users to make payments off-chain. The current mechanism in use for this payment system requires both parties to sign on transactions before they can be executed. However, there are some practical constraints that need to be considered for 2-party channels with eltoo. These include fast forwards, doubled delays, penalties, and trustless watchtowers. In response to these issues, a rough approach has been developed. This approach involves each party maintaining five transactions: UA.n, UB.n, WA.n, WB.n, CA.n, CB.n, SA.n, SB.n, RA.n, and RB.n. The transactions require pre-signed signatures, but the actual transaction/txid will vary based on the possibility of spending different inputs.Scenarios where Alice decides to unilaterally close the channel might look like if Alice/Bob can't communicate directly, but both are online or if Bob has gone offline entirely. Additionally, Alice cheats, Bob punishes; Bob is offline, Alice cheats, but Bob has a watchtower; Alice and Bob's watchtower collude, but Bob's not offline, and Alice and Bob's watchtower collude, but Bob has many watchtowers can occur.To allow fast-forwards, when Alice proposes a new state, she needs to send her partial signatures to allow Bob to unilaterally accept the new state. Nonetheless, if Alice proposes UA. (n-1) (her most recent state), Bob can still immediately claim via CA.n. If Bob did have WB.n, then if Alice proposed UA. (n-1), Bob could wait for an initial to_self_delay period and broadcast WB.n, forcing Alice to wait for an additional to_self_delay before being able to claim her funds via SA.The email thread discusses various issues related to the Lightning Network. It is mentioned that RA.n/RB.n requires "k" and Alice would be able to broadcast UA. (n-1) but Bob can penalize her by broadcasting RB.n. If a watchtower is used to punish cheating, only WA. (n-2) should be passed to it instead of WA. (n-1) or WA.n. However, there are potential issues related to adding fees, payment to watchtowers, lack of layered transactions, and extending to multiparty channels. Adding fees to U/W transactions and C/S/R transactions is not trivial, and watchtowers need to be compensated for adding fees when broadcasting a W transaction. Layered transactions are also missing, making some htlc claimable on-chain and requiring cltv_expiry_delta >= to_self_delay. Extending to multiparty channels is also difficult due to penalizing, coordinating state updates, and keeping everyone online consistently.
Updated on: 2023-06-03T11:11:14.468186+00:00