📅 Original date posted:2022-03-16
📝 Original message:
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 < elzeigel at 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 <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/20220316/fd4e1c3d/attachment-0001.html>;
darosior [ARCHIVE] /
npub1pj…x22xp
2023-06-09 13:05:29
in reply to nevent1q…awa0
Author Public Key
npub1pj9022f74rzq7d5x7gnxje6wpsgk4r5jgeck8y5awd423ydhan3q7x22xpPublished at
2023-06-09 13:05:29Event JSON
{
"id": "a0a6ded8dbf67bda8364e5edadf78f3a790ca1e6806b917744c0d1897e53d671",
"pubkey": "0c8af5293ea8c40f3686f22669674e0c116a8e92467163929d736aa891b7ece2",
"created_at": 1686315929,
"kind": 1,
"tags": [
[
"e",
"0e07698145199f16ce6d2ffcc9b8f0c33028caf6726f5d0ccfd2b96707290d52",
"",
"root"
],
[
"e",
"77b6aecf0462aeb93d8dee7cee7ff213ca284efaa207531e0bec79770aa9c74e",
"",
"reply"
],
[
"p",
"897fddf7e8d6dceae0590dbd4ecf88e3702c23e1384b9916dd4eecc41896af39"
]
],
"content": "📅 Original date posted:2022-03-16\n📝 Original message:\nMiniscripts with duplicate keys are considered insane as it makes it too hard to reason about malleability (there is no CODESEPARATOR in Miniscript).\n\nA policy compiler would never produce such a Miniscript.\n\n-------- Original Message --------\nOn Mar 15, 2022, 4:26 PM, Eugene Siegel \u003c elzeigel at gmail.com\u003e wrote:\n\n\u003e I'm not familiar with miniscript besides that it's a subset of script - how would it help avoiding an unintended path being taken?\n\u003e\n\u003e On Fri, Mar 11, 2022 at 8:47 AM darosior \u003cdarosior at protonmail.com\u003e wrote:\n\u003e\n\u003e\u003e Also, using Miniscript (whether in Segwit v0 or v1) would prevent this kind of surprises. And many potential others. :-)\n\u003e\u003e\n\u003e\u003e I'll post something soon about how we could integrate Miniscript in Lightning.\n\u003e\u003e -------- Original Message --------\n\u003e\u003e On Mar 10, 2022, 2:55 PM, Eugene Siegel \u003c elzeigel at gmail.com\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e Yes I think bip342 should solve it. Maybe splitting up all conditionals into leaves is a good idea for taproot lightning\n\u003e\u003e\u003e\n\u003e\u003e\u003e On Mon, Mar 7, 2022 at 5:46 PM Antoine Riard \u003cantoine.riard at gmail.com\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e Hi Eugene,\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e Since the remote party gives them a signature, after the timeout, the offering party can\n\u003e\u003e\u003e\u003e claim with the remote's signature + preimage, but can only spend with the\n\u003e\u003e\u003e\u003e HTLC-timeout transaction because of SIGHASH_ALL.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e I've not exercised the witness against our test framework though the description sounds to me correct.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e The offering counterparty spends the offered HTLC output with a HTLC-timeout transaction where the witness is \u003c\u003cremote_sig\u003e \u003cpayment_preimage\u003e\u003e. 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.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e 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.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e Antoine\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e Le lun. 7 mars 2022 à 15:27, Eugene Siegel \u003celzeigel at gmail.com\u003e a écrit :\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e 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.\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e https://github.com/lightning/bolts/blob/master/03-transactions.md#offered-htlc-outputs\n\u003e\u003e\u003e\u003e\u003e 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.\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e Eugene (Crypt-iQ on github)\n\u003e\u003e\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e\u003e\u003e Lightning-dev mailing list\n\u003e\u003e\u003e\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220316/fd4e1c3d/attachment-0001.html\u003e",
"sig": "c2e1e7aef327b6ed5dacdbbe5007526edf0b71d61aaefa57cb6457835f0406fc490c3acbcee858784d8ea0363a0a80734200cdc9cf378484e917412c7ffdc230"
}