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 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 <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
