What is Nostr?
Rusty Russell [ARCHIVE] /
npub1zw7…khpx
2023-06-09 12:43:50
in reply to nevent1q…jwpw

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.
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx