From elzeigel at gmail.com Tue Mar 15 15:26:25 2022 From: elzeigel at gmail.com (Eugene Siegel) Date: Tue, 15 Mar 2022 11:26:25 -0400 Subject: [Lightning-dev] Interesting thing about Offered HTLCs In-Reply-To: References: Message-ID: I'm not familiar with miniscript besides that it's a subset of script - how would it help avoiding an unintended path being taken? On Fri, Mar 11, 2022 at 8:47 AM darosior wrote: > Also, using Miniscript (whether in Segwit v0 or v1) would prevent this > kind of surprises. And many potential others. :-) > > > I'll post something soon about how we could integrate Miniscript in > Lightning. > -------- Original Message -------- > On Mar 10, 2022, 2:55 PM, Eugene Siegel < elzeigel at gmail.com> wrote: > > > 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 > 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 < >> >. 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 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 at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: