📅 Original date posted:2016-03-09
📝 Original message:
>From IRC:
<rusty> Hmm, what term should I use in documentation for the
failure mode where a node uses too tight a timeout and ends up
paying out an outgoing HTLC but unable to redeem the incoming
HTLC?
<rusty> "one-sided redemption" is what I came up with, but it's not very
punchy for "you screwed up and lost money"
That's too loose a timeout, isn't it? You choose the timeout for your
outgoing payment, so if the incoming timeout runs out, your outgoing
timeout was too long.
I'd just call it "avoiding timeout on incoming HTLC when forwarding"
or similar?
On Wed, Mar 09, 2016 at 11:13:36AM +1030, Rusty Russell wrote:
> Confusingly, we also use "revocation preimage" as the term method to
> invalidate old transactions, a private matter between pairs of nodes,
> but try to avoid abbreviating it to R.
Yeah, the lack of an obvious abbreviation for the revocation preimage
has bugged me a couple of times. What about saying we "void" the old
commitment, and use "V" as the symbol for the hash/signature/whatever?
(R for the HTLC "receipt" seems to work okay so probably good to keep
that)
Cheers,
aj
Anthony Towns [ARCHIVE] /
npub17r…x9l2h
2023-06-09 12:45:58
in reply to nevent1q…863q
Author Public Key
npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hPublished at
2023-06-09 12:45:58Event JSON
{
"id": "2dfdbc6628c602f6f4d432dd2ff808c9ae652e2ed29317a179923aba24dc0d43",
"pubkey": "f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab",
"created_at": 1686314758,
"kind": 1,
"tags": [
[
"e",
"5153df3706cf63df82164e66cdbe540fbaa58836d1e8c627e0385858c8ca57db",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2016-03-09\n📝 Original message:\n\u003eFrom IRC:\n\n\u003crusty\u003e Hmm, what term should I use in documentation for the\n failure mode where a node uses too tight a timeout and ends up\n paying out an outgoing HTLC but unable to redeem the incoming\n HTLC?\n\u003crusty\u003e \"one-sided redemption\" is what I came up with, but it's not very\n punchy for \"you screwed up and lost money\"\n\nThat's too loose a timeout, isn't it? You choose the timeout for your\noutgoing payment, so if the incoming timeout runs out, your outgoing\ntimeout was too long.\n\nI'd just call it \"avoiding timeout on incoming HTLC when forwarding\"\nor similar?\n\nOn Wed, Mar 09, 2016 at 11:13:36AM +1030, Rusty Russell wrote:\n\u003e Confusingly, we also use \"revocation preimage\" as the term method to\n\u003e invalidate old transactions, a private matter between pairs of nodes,\n\u003e but try to avoid abbreviating it to R.\n\nYeah, the lack of an obvious abbreviation for the revocation preimage\nhas bugged me a couple of times. What about saying we \"void\" the old\ncommitment, and use \"V\" as the symbol for the hash/signature/whatever?\n\n(R for the HTLC \"receipt\" seems to work okay so probably good to keep\nthat)\n\nCheers,\naj",
"sig": "c20df1510c35ce099f20056e3ad59a3052dc01f2151db9456adf1b5b0c75830785bc2076225b489eb55633f1d2769d59bd4142a04939c8b6a9ccb73abb841207"
}