Published on: 2015-11-30T01:25:54+00:00
In a discussion between Anthony Towns and Rusty Russell, several constraints and calculations related to timeouts and commitment transactions in the Lightning Network are discussed. Anthony suggests adding further constraints on timeouts based on fees and batching timeouts for better efficiency. He proposes expiring 1000 concurrent HTLCs on a channel in five batches of 20 instead of individually, which results in significant savings in transaction size. The maximum number of concurrent committed HTLCs on a channel is determined by the 100kB standardness limit on transactions.The conversation also revolves around determining the timeout on outgoing HTLCs. Factors such as timeout (T), CSV delay (d), confirmation time (n), and fee paid (f) are taken into account. If an HTLC has not been resolved off-chain at T-d-f, the commitment transaction needs to be published. At T, both the CTLV and CSV clauses are satisfied, allowing one to spend it. The transaction will be confirmed at T+f, and at T+f+n, one can be confident that the transaction is safe. Bob wants to determine the timeout for the outgoing HTLC to keep the channel with Alice open.The discussion continues with Rusty Russell and Anthony Towns discussing the enforcement of constraints for HTLCs and commitment transactions. They discuss the delay (d) of OP_CSV, top OP_CLTV timeout (T), commitment tx signed by B and given to A at time C, commitment tx published at time P, commitment tx spent at time S, and the timeout at which a refund can be forced (X). The importance of revocation time and the HTLC inter-hop-delta is highlighted to spot cheating and ensure safe transactions. Anthony proposes requiring proof that a commit tx was published if there is no fast resolution on an HTLC, but the issue arises when the number of hops ahead is unknown.Anthony Towns defines several variables related to commitment transactions in a post. He mentions the need for parameters "t" and "k" as well as "d" to be dropped to the blockchain before T comes around. However, he gets lost while reading a related question about the timeout of HTLC offers. The proposal to require proof of a commit tx being published or closing the channel oneself to create such proof is discussed, but setting a fixed timeout for all nodes could result in simultaneous closure of channels.The constraints and conditions imposed by Bitcoin on HTLCs and commitment transactions are discussed. The enforcement of these constraints is crucial for secure and efficient transactions. The issue of race conditions and the need for separate timeframes for claiming a payment and revoking an output is highlighted. Mats Jerratsch discovers issues with the design of single output scripts and commit transactions, which prevent long revocation times and short refund times simultaneously. The absolute CLTV timeout must increase with each hop, but this can provide insight into the position within the route. Mats suggests separating the two actions into two layers and enforcing revealing R within a separate timeframe. However, this would require additional features like SIGHASH_NOINPUT or SW.In conclusion, the discussion focuses on the importance of constraints and timeouts in the Lightning Network to ensure secure and efficient transactions. Various proposals and calculations are discussed to address challenges and improve the protocol.
Updated on: 2023-07-31T18:41:06.200913+00:00