Published on: 2023-01-06T04:19:53+00:00
In a recent email exchange, Bitcoin developer Antoine Riard discussed the eltoo implementation in the Lightning Network and highlighted potential vulnerabilities. The discussion focused on breaking symmetry to distinguish between unilateral closures by one party and cheating attempts. It also touched upon the delay in redeeming an HTLC that times out in the future and the use of CLTV for eltoo state ratcheting.The conversation further explored the difference between CA.n and UB.n/WA.n transactions and the role of watchtowers in preventing dishonest behavior. A scenario was presented where Alice could steal funds by posting an old transaction, provided her balance at that time was significantly less than her current balance. The risks of delegating punishment to untrusted watchtowers were also discussed, and an alternative setup was suggested.The discussion between Antoine Riard and Anthony Towns revolved around the eltoo/chia variant, which aims to simplify the implementation process by introducing a cryptographic puzzle. This variant allows for the production of witness once and only once, simplifying the two-party setup and making it easier to reason about its limits. The construction ensures a strict bound on the shared_delay encumbered in the on-chain publication of the channel.There was also mention of a "fast-forward" protocol upgrade proposal that could significantly speed up payment forwarding in the Lightning Network. Concerns were raised regarding locked-up funds if the recipient goes offline and the possibility of Bob attempting to confirm his own unilateral close. Proposed solutions included using partial signatures and adaptor signature or CTV-like approaches.The email thread delved into the challenges related to paying watchtowers fairly and reliably in the Lightning Network. One suggestion was to give the watchtower a pre-signed transaction with an initial capacity reflecting the user's willingness to contribute in fees. The user could claim a penalty via this transaction if the watchtower acts improperly.Antoine and Greg discussed the eltoo payment channel construction using V3+ephemeral anchors, addressing concerns about potential attacks and relative timelocks. They discussed the advantages of eltoo, such as limiting the publication of states more than once by a counterparty and reducing latency of HTLC propagation across payment paths. Concerns related to doubled delays and penalties for cheating were also mentioned.The email thread touched upon various issues in the Lightning Network ecosystem, including watchtower designs, transaction cycles, and learning. Proposed solutions involved adapting CTV-like approaches, using SINGLE/ANYONECANPAY signatures to add fees, and introducing more efficient fee-bumping primitives. Security perspectives were considered, including offsetting cltv_expiry_delta and coordinating multiparty state updates.The email thread also addressed practical constraints and challenges in implementing eltoo for two-party channels. These included fast forwards, doubled delays, penalties, and trustless watchtowers. Various scenarios involving unilateral closures by Alice, potential cheating, and watchtower collusion were discussed.Efforts were made to optimize eltoo for two-party scenarios, but there are practical constraints to consider, such as extending it to multiparty channels, adding fees, and paying watchtowers. Coordinating multiparty state updates and maintaining consistent online presence posed challenges.Overall, the discussions highlighted the innovations, vulnerabilities, and proposed solutions in the implementation of eltoo and its variants in the Lightning Network. The aim is to simplify the channel construction, improve payment forwarding, address security concerns, and ensure fair compensation for watchtowers.The Lightning-dev mailing list has been discussing the optimization of eltoo for the 2-party scenario. In this context, Alice needs Bob to be offline for a certain duration and for all of Bob's watchtowers to also be offline or colluding. This allows Alice to propose new states and broadcast transactions named *A.n, while Bob can do the same with *B.n transactions. Alice must send her partial signatures to Bob when proposing a new state, enabling him to unilaterally accept it. However, she also needs to be able to claim the funds if Bob proposes the new state and broadcasts UB.n.To address these challenges, the post suggests using an adaptor signature approach or a CTV-like approach. However, extending eltoo to multiparty channels presents additional difficulties. Penalizing becomes harder with more than two parties, fast forwards may be impossible, and coordinating multiparty state updates is potentially challenging. The post also highlights issues such as adding fees and paying watchtowers, lack of layered transactions, and expanding to multiparty channels.The author focuses on optimizing eltoo for the two-party scenario, where Alice and Bob are the only participants. In this case, if Alice initiates a unilateral close, only Bob's opinion matters afterward. This simplifies various aspects, including allowing for fast forwards, doubled delays, penalties, and trustless watchtowers. The post provides a rough approach to address these issues in two-party channels but acknowledges that it may not be necessary or feasible to handle all constraints in initial eltoo experimentation.
Updated on: 2023-08-01T00:55:37.825929+00:00