bitcoin-dev
OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
Posted on: November 14, 2023 19:50 UTC
The correspondence begins by distinguishing two separate issues identified by the recipient, emphasizing that revoked states and HTLCs (Hashed Time-Locked Contracts) are fundamentally different.
Revoked states are fraudulent actions within punishment-based protocols and carry high risks of financial loss if detected. Improvements to enhance security in these protocols are deemed possible, suggesting that there is room for refinement.
In discussing the economics of Lightning channels, it is noted that for such channels to be viable, the maximum feasible fee must remain modest relative to the total value within the channel. Allocating a small portion of channel capacity for potential future fees is not considered a significant cost burden. The idea of an attack wherein miners prioritize commitment transactions with high HTLC values for increased fees is dismissed as illogical, since miners profit from the difference in feerate—not the entire HTLC value—when they forgo mining other transactions.
It is further argued that the sum of trimmed HTLCs should be capped at a level consistent with reasonable transaction fees, highlighting the absurdity of scenarios where a disproportionate amount of the channel's value is consumed by fees. This points to a need to rectify this flaw in existing implementations.
Regarding Replace-by-Fee (RBF) fee bumping, the writer acknowledges that increased fees can be allocated to the party broadcasting the commitment transaction. However, they reiterate that it is impractical for channel closures to incur substantial fees as a percentage of the channel's value. The author questions the existence of a concrete attack based on the current discussion.
The use of SIGHASH_NOINPUT for signing HTLC refund transactions in RBF replacements is mentioned as a solution to avoid requiring multiple distinct refund transactions for each feerate of the commitment transaction. Nevertheless, no comments are offered on RBF replacements involving LN-Symmetry due to its perceived flaws in non-trusted environments.
Finally, the email implies that removing 'justice'—a mechanism to penalize fraud—from the Lightning Network would result in severe insecurity unless there exists a degree of trust between parties. In cases where LN-Symmetry is employed securely, concerns about counterparts engaging in 'fee games' are minimized. The email concludes with a link to the sender's website and provides a modified email address for further contact.