📅 Original date posted:2020-04-05
📝 Original message:
Hi ZmnSCPxj,
This is a rework of the old unwrap-the-onion proposal, with
some important bits missing.
> Secondly, C needs to prove that the channel it is willing to close involves the payment attempt, and is not some other channel closure that it is attempting to use to fulfill its own soft timeout.
> Since the unilateral close transaction *is* the proof-of-closure, B (and A) can inspect the transaction outputs and see (with some additional data from C) that one of the outputs is to an HTLC that matches the payment hash.
>
> Thus, B (and A) can believe that the proof-of-closure proves that whoever is presenting it is free of wrongdoing, as whoever is actually causing the delay has been punished (by someone being willing to close a channel with the culprit), and that the proof-of-closure commits to this particular payment attempt and no other (because it commits to a particular payment hash).
As you note below, the payment might be considered dust, or an
unresponsive peer has not yet acked the HTLC.
My previous proposal was to limit the damage somewhat by requiring that
C offer a signed list of some limited number of HTLCs it is claiming
were caught, alongside the closure proof (you can merkle this, but
that's a detail). That closure claim gets socialized, and if there are
multiple different claim lists for the tx then C is a bad actor and we
no longer respect its closure proof.
You also missed how the timeout would work, which is important. How
long does node N wait for a proof? In my construction, it's 30 seconds,
plus get another 30 seconds for each decryption of the onion it
receives.
Otherwise, you can't know how long you've got to provide this closure
proof, or how long to wait for it.
In addition, for closure proofs to work, nodes need to agree on what is
a valid, standard, high-enough-fee commitment transaction.
Cheers,
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:59:24
in reply to nevent1q…lr2u
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:59:24Event JSON
{
"id": "dbdd7fc0a014bf2a591d2bedb8f9a98a9c3815935e25f53c8a4d291040e71163",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686315564,
"kind": 1,
"tags": [
[
"e",
"5e9b3eb7b6e686adb024bff8716ce0db1903914f4eed2a9ca1348e890d04a69e",
"",
"root"
],
[
"e",
"cb418d2458640ffdc71b2f18048d22cf9e9e9e4e6e32440c9e6f5e64df768928",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2020-04-05\n📝 Original message:\nHi ZmnSCPxj,\n\n This is a rework of the old unwrap-the-onion proposal, with\nsome important bits missing.\n\n\u003e Secondly, C needs to prove that the channel it is willing to close involves the payment attempt, and is not some other channel closure that it is attempting to use to fulfill its own soft timeout.\n\u003e Since the unilateral close transaction *is* the proof-of-closure, B (and A) can inspect the transaction outputs and see (with some additional data from C) that one of the outputs is to an HTLC that matches the payment hash.\n\u003e\n\u003e Thus, B (and A) can believe that the proof-of-closure proves that whoever is presenting it is free of wrongdoing, as whoever is actually causing the delay has been punished (by someone being willing to close a channel with the culprit), and that the proof-of-closure commits to this particular payment attempt and no other (because it commits to a particular payment hash).\n\nAs you note below, the payment might be considered dust, or an\nunresponsive peer has not yet acked the HTLC.\n\nMy previous proposal was to limit the damage somewhat by requiring that\nC offer a signed list of some limited number of HTLCs it is claiming\nwere caught, alongside the closure proof (you can merkle this, but\nthat's a detail). That closure claim gets socialized, and if there are\nmultiple different claim lists for the tx then C is a bad actor and we\nno longer respect its closure proof.\n\nYou also missed how the timeout would work, which is important. How\nlong does node N wait for a proof? In my construction, it's 30 seconds,\nplus get another 30 seconds for each decryption of the onion it\nreceives.\n\nOtherwise, you can't know how long you've got to provide this closure\nproof, or how long to wait for it.\n\nIn addition, for closure proofs to work, nodes need to agree on what is\na valid, standard, high-enough-fee commitment transaction.\n\nCheers,\nRusty.",
"sig": "36116f9b8f8465a1b18c608f3a4de37cfc3d7d0947757c70994e31583a49376fc123b25299a00dc1f0a8c0b88ec5107bf9770c931af87d76111063ee8610e8d1"
}