Eugene Siegel [ARCHIVE] on Nostr: 📅 Original date posted:2022-03-10 📝 Original message: Yes I think bip342 should ...
📅 Original date posted:2022-03-10
📝 Original message:
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.riard at 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 <elzeigel at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220310/dbf38c56/attachment.html>;
📝 Original message:
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.riard at 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 <elzeigel at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220310/dbf38c56/attachment.html>;