Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-29 📝 Original message: Christopher Jamthagen ...
📅 Original date posted:2015-07-29
📝 Original message:
Christopher Jamthagen <cjamthagen at gmx.com> writes:
> Still trying to get the details right of this protocol. Please correct
> me if I am wrong in any of my assumptions below.
> Assume a payment route: Alice<>Bob<>Carol
> Alice want to pay Carol some amount. Carol gives Alice H(R) and Alice
> updates her commitment tx with Bob including the HTLC output and Bob
> does the same with Carol.
OK.
> Carol witholds R, forcing Bob to broadcast the commitment tx between
> Bob and Carol.
Yep, Carol goes non-responsive. Got it.
> Carol can now spend the HTLC output because she knows R and thus
> revealing it to the world. Alice now also refuses to update the
> commitment tx with Bob, forcing Bob to broadcast that commitment tx.
Poor Bob. Yep.
> This commitment tx is putting a delay on
> Bobs ability to spend the HTLC output (as well as all other outputs to
> him), but Alice can spend the HTLC output if the CLTV has expired.
Indeed, don't ever offer an HTLC less than your delay!
> In most examples I have seen, the CLTV is 2 days between Alice and Bob
> and 1 day between Bob and Carol, and all CSV delays are 3 days.
I haven't seen an example which included a CSV delay amount.
As the discussion with Joseph is establishing, the minimum CSV you allow
controls the worst-case HTLC you can accept. CSV of a few hours should
be OK if you're online all the time. I think...
Anyone want to do some stats on that? CSV uses the median time of last
11 blocks, so to some extent you can tell the worst case...
Cheers,
Rusty.
Published at
2023-06-09 12:43:50Event JSON
{
"id": "a257bff9fd2c2ad0f868afab0ba2d94ad5db5c383146d94dbfae7ef551fca9c1",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314630,
"kind": 1,
"tags": [
[
"e",
"03990f127b6e54e518e627269d29601b4135cf31490a121eebe8865e4878ad6a",
"",
"root"
],
[
"e",
"18d0bbb39963a1f3625edcff672cb076b8005473b6f3ef3313804b13b16539a9",
"",
"reply"
],
[
"p",
"ad104cac8fd9919c65a2df9e910166f2a1513845fdfa37fd10f1063eb12f5254"
]
],
"content": "📅 Original date posted:2015-07-29\n📝 Original message:\nChristopher Jamthagen \u003ccjamthagen at gmx.com\u003e writes:\n\u003e Still trying to get the details right of this protocol. Please correct\n\u003e me if I am wrong in any of my assumptions below.\n\n\u003e Assume a payment route: Alice\u003c\u003eBob\u003c\u003eCarol\n\n\u003e Alice want to pay Carol some amount. Carol gives Alice H(R) and Alice\n\u003e updates her commitment tx with Bob including the HTLC output and Bob\n\u003e does the same with Carol.\n\nOK.\n\n\u003e Carol witholds R, forcing Bob to broadcast the commitment tx between\n\u003e Bob and Carol.\n\nYep, Carol goes non-responsive. Got it.\n\n\u003e Carol can now spend the HTLC output because she knows R and thus\n\u003e revealing it to the world. Alice now also refuses to update the\n\u003e commitment tx with Bob, forcing Bob to broadcast that commitment tx.\n\nPoor Bob. Yep.\n\n\u003e This commitment tx is putting a delay on\n\u003e Bobs ability to spend the HTLC output (as well as all other outputs to\n\u003e him), but Alice can spend the HTLC output if the CLTV has expired.\n\nIndeed, don't ever offer an HTLC less than your delay!\n\n\u003e In most examples I have seen, the CLTV is 2 days between Alice and Bob\n\u003e and 1 day between Bob and Carol, and all CSV delays are 3 days.\n\nI haven't seen an example which included a CSV delay amount.\n\nAs the discussion with Joseph is establishing, the minimum CSV you allow\ncontrols the worst-case HTLC you can accept. CSV of a few hours should\nbe OK if you're online all the time. I think...\n\nAnyone want to do some stats on that? CSV uses the median time of last\n11 blocks, so to some extent you can tell the worst case...\n\nCheers,\nRusty.",
"sig": "33bf0f533496a073567fc5adfab6a8f766c47fc6c3b53a422a9c184be31a9f2c7c6f7741e591a6d1277d75a6cf1c8f98f94f0162096f8eb63be1820b7805b79d"
}