Author: Antoine Riard 2022-03-07 22:46:07
Published on: 2022-03-07T22:46:07+00:00
In an email conversation, Antoine discusses the implications of offered HTLC outputs with Eugene. The offering counterparty spends the offered HTLC output with a HTLC-timeout transaction where the witness is not committing to the spent Script branch intended to be used. SIGHASH_ALL does not alleviate the offering counterparty to respect the CLTV delay and as such, the offered HTLC timespan cannot be shortened. In case of competing HTLC race, once the absolute timelock is expired, the offering counterparty is able to compete against the receiving one with a more feerate-efficient witness. However, from a receiving counterparty safety viewpoint, if you're already suffering a contest, it means your HTLC-claim on your own local commitment transaction inbound HTLC output has been inefficient, and your fee-bumping strategy is to blame. If they think the issue is relevant, Antoine believes splitting the Script branches in two tapleaves and having bip342 signature digest committing to the tapleaf_hash solves it. Meanwhile, Eugene shares his findings on offered HTLCs having three claim paths: the revocation case, the offerer claiming through the HTLC-timeout transaction, and the receiver claiming via their sig + preimage. They note that since the remote party gives them a signature, after the timeout, the offering party can claim with the remote's signature + preimage, but can only spend with the HTLC-timeout transaction because of SIGHASH_ALL. This assumes that the remote party doesn't claim it first. Eugene doesn't see any cases where the offering party would know the preimage AND want to force close, so he thinks it's benign.
Updated on: 2023-06-03T07:44:46.462686+00:00