Miniscripts with duplicate keys are considered insane as it makes it too hard
to reason about malleability (there is no CODESEPARATOR in Miniscript).
A policy compiler would never produce such a Miniscript.
-------- Original Message --------
On Mar 15, 2022, 4:26 PM, Eugene Siegel < elzei...@gmail.com> wrote:
> 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 <daros...@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 < elzei...@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.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
