Author: Christopher Jamthagen 2015-08-02 18:36:07
Published on: 2015-08-02T18:36:07+00:00
In a discussion about the timestop feature, concerns were raised that if this feature was only activated when the CLTV transaction was included in a block, it could lead to a DoS attack vector where hubs can be forced to close channels with other hubs. The solution proposed was that the rule should be "time doesn't pass if a block is full," but it would be necessary to explicitly supply the block-height at which the transaction was signed. A clarification was made that during a block-filling attack, the HTLC wouldn't expire, but there would be no reason to panic and dump transactions as there is all the time in the world. It was suggested that preventing HTLCs from expiring is a lesser DoS.It was also noted that CLTV transactions would need to include the current block-height immediately when a commitment transaction is signed so that miners can know where to start counting full blocks from. This would require an upgrade for CLTV, and it was clarified that such an upgrade would be soft-forkable. A separate thread discussed the scalability of outsourcability and how it can be automated by including fees in the "steal" transaction. However, a concern was raised about remembering R values and timeouts. Finally, it was mentioned that watching the chain for spends on anchor outputs would only require work when one of them gets spent, which should almost never happen since the client should tell the third party they're going to close the channel cooperatively.
Updated on: 2023-05-23T18:58:10.110274+00:00