Yes I think bip342 should solve it. Maybe splitting up all conditionals into leaves is a good idea for taproot lightning
On Mon, Mar 7, 2022 at 5:46 PM Antoine Riard <antoine.ri...@gmail.com> wrote: > Hi Eugene, > > > 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. > > I've not exercised the witness against our test framework though the > description sounds to me correct. > > The offering counterparty spends the offered HTLC output with a > HTLC-timeout transaction where the witness is <<remote_sig> > <payment_preimage>>. SIGHASH_ALL is not committing to the spent Script > branch intended to be used. As you raised, it doesn't alleviate the > offering counterparty to respect the CLTV delay and as such the offered > HTLC timespan cannot be shortened. The implication I can think of, 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 we think the issue is relevant, I believe splitting the Script branches > in two tapleaves and having bip342 signature digest committing to the > tapleaf_hash solves it. > > Antoine > > Le lun. 7 mars 2022 à 15:27, Eugene Siegel <elzei...@gmail.com> a écrit : > >> I'm not sure if this is known, but I'm pretty sure it's benign and so I >> thought I'd share since I found it interesting and maybe someone else will >> too. I'm not sure if this is already known either. >> >> >> https://github.com/lightning/bolts/blob/master/03-transactions.md#offered-htlc-outputs >> Offered HTLCs have three claim paths: the revocation case, the offerer >> claiming through the HTLC-timeout transaction, and the receiver claiming >> via their sig + preimage. The offering party can claim via the HTLC-timeout >> case on their commitment transaction with their signature and the remote's >> signature (SIGHASH_ALL) after the cltv_expiry timeout. 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. I can't think of any cases where the >> offering party would know the preimage AND want to force close, so that's >> why I think it's benign. It does make the witness smaller. The same trick >> isn't possible with the Received HTLC's due to OP_CHECKLOCKTIMEVERIFY. >> >> Eugene (Crypt-iQ on github) >> _______________________________________________ >> Lightning-dev mailing list >> Lightning-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
