📅 Original date posted:2022-03-07
📝 Original message:
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/20220307/b55f369a/attachment.html>;
Antoine Riard [ARCHIVE] /
npub1vj…4x8dd
2023-06-09 13:05:28
in reply to nevent1q…fjd6
Author Public Key
npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8ddPublished at
2023-06-09 13:05:28Event JSON
{
"id": "bd04ba701be88eb92f1c9b6810c322d1c217ef6bbdad2b9437d269a63ecb7b67",
"pubkey": "6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551",
"created_at": 1686315928,
"kind": 1,
"tags": [
[
"e",
"0e07698145199f16ce6d2ffcc9b8f0c33028caf6726f5d0ccfd2b96707290d52",
"",
"root"
],
[
"e",
"85b9c661f3b7894c893b1bc6a9d1b11a7a114f1ab1ce8e978d6dd6464745df6d",
"",
"reply"
],
[
"p",
"897fddf7e8d6dceae0590dbd4ecf88e3702c23e1384b9916dd4eecc41896af39"
]
],
"content": "📅 Original date posted:2022-03-07\n📝 Original message:\nHi Eugene,\n\n\u003e Since the remote party gives them a signature, after the timeout, the\noffering party can\nclaim with the remote's signature + preimage, but can only spend with the\nHTLC-timeout transaction because of SIGHASH_ALL.\n\nI've not exercised the witness against our test framework though the\ndescription sounds to me correct.\n\nThe offering counterparty spends the offered HTLC output with a\nHTLC-timeout transaction where the witness is \u003c\u003cremote_sig\u003e\n\u003cpayment_preimage\u003e\u003e. SIGHASH_ALL is not committing to the spent Script\nbranch intended to be used. As you raised, it doesn't alleviate the\noffering counterparty to respect the CLTV delay and as such the offered\nHTLC timespan cannot be shortened. The implication I can think of, in case\nof competing HTLC race, once the absolute timelock is expired, the offering\ncounterparty is able to compete against the receiving one with a more\nfeerate-efficient witness. However, from a receiving counterparty safety\nviewpoint, if you're already suffering a contest, it means your HTLC-claim\non your own local commitment transaction inbound HTLC output has been\ninefficient, and your fee-bumping strategy is to blame.\n\nIf we think the issue is relevant, I believe splitting the Script branches\nin two tapleaves and having bip342 signature digest committing to the\ntapleaf_hash solves it.\n\nAntoine\n\nLe lun. 7 mars 2022 à 15:27, Eugene Siegel \u003celzeigel at gmail.com\u003e a écrit :\n\n\u003e I'm not sure if this is known, but I'm pretty sure it's benign and so I\n\u003e thought I'd share since I found it interesting and maybe someone else will\n\u003e too. I'm not sure if this is already known either.\n\u003e\n\u003e\n\u003e https://github.com/lightning/bolts/blob/master/03-transactions.md#offered-htlc-outputs\n\u003e Offered HTLCs have three claim paths: the revocation case, the offerer\n\u003e claiming through the HTLC-timeout transaction, and the receiver claiming\n\u003e via their sig + preimage. The offering party can claim via the HTLC-timeout\n\u003e case on their commitment transaction with their signature and the remote's\n\u003e signature (SIGHASH_ALL) after the cltv_expiry timeout. Since the remote\n\u003e party gives them a signature, after the timeout, the offering party can\n\u003e claim with the remote's signature + preimage, but can only spend with the\n\u003e HTLC-timeout transaction because of SIGHASH_ALL. This assumes that the\n\u003e remote party doesn't claim it first. I can't think of any cases where the\n\u003e offering party would know the preimage AND want to force close, so that's\n\u003e why I think it's benign. It does make the witness smaller. The same trick\n\u003e isn't possible with the Received HTLC's due to OP_CHECKLOCKTIMEVERIFY.\n\u003e\n\u003e Eugene (Crypt-iQ on github)\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220307/b55f369a/attachment.html\u003e",
"sig": "20968e4ef97923917d8f5a1498cb38c0b23c6102e72dd328a54bac4e78cc1d2506df54f6a84cc7bb2eaac2fc3a20694b049f1d7bb72b70acc42e9d44c86ef10f"
}