Eugene Siegel [ARCHIVE] on Nostr: 📅 Original date posted:2022-03-15 📝 Original message: I'm not familiar with ...
📅 Original date posted:2022-03-15
📝 Original message:
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 <darosior at protonmail.com> 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 <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/20220315/f3f7ac11/attachment.html>;
📝 Original message:
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 <darosior at protonmail.com> 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 <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/20220315/f3f7ac11/attachment.html>;