📅 Original date posted:2015-07-30
📝 Original message:
Sent: Thursday, July 30, 2015 at 4:41 AM
From: "Rusty Russell" <rusty at rustcorp.com.au>
To: "Christopher Jamthagen" <cjamthagen at gmx.com>, "lightning-dev at lists.linuxfoundation.org" <lightning-dev at lists.linuxfoundation.org>
Subject: Re: [Lightning-dev] Stealing money from a hub?
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!
Yes, now that you mention it :)
If we assume that Gregory Maxwell's timestop feature is in use to further delay the expiration of a CSV in the case of full (or near-full) blocks. If this is used, the counterparty can just fill the blocks for a limited amount of time until his CLTV has expired and then take the HTLC output. I guess the time between CSV expiration and CLTV expiration can be adjusted depending on the value being transferred.
Would it be desirable/possible to implement the timestop feature for CLTV as well? That would make the difference between the number of blocks until either expiration the same in case of a block-filling attack. If I'm not mistaken Peter Todds BIP is already merged, but this feature could be implemented with another soft fork.
>> 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...
Speaking of being online all the time, checking the blockchain is outsourceable, right? So it seems that miners would be the perfect third party to check for cheaters in LN. By offering them a nice chunk of our counterparty's funds as fees, they should be incentiviced enough to keep an extra eye for us on the blockchain.
> 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.
Christopher Jamthagen [ARCHIVE] /
npub145…cvvwf
2023-06-09 12:43:50
in reply to nevent1q…4lnp
Author Public Key
npub145gyety0mxgecedzm70fzqtx72s4zwz9lhar0lgs7yrravf02f2qvcvvwfPublished at
2023-06-09 12:43:50Event JSON
{
"id": "edc50b24969520bca76178cb277a42769eac2975fe1cc99c1026ed1e92fe3856",
"pubkey": "ad104cac8fd9919c65a2df9e910166f2a1513845fdfa37fd10f1063eb12f5254",
"created_at": 1686314630,
"kind": 1,
"tags": [
[
"e",
"03990f127b6e54e518e627269d29601b4135cf31490a121eebe8865e4878ad6a",
"",
"root"
],
[
"e",
"48feb6f0c8ae72b2c11155ec38e20824f3a106029c68d0b57d206f1c2455722e",
"",
"reply"
],
[
"p",
"f5854a07c480aa95b00a3106a17778f7b58221d8dd12d11e6d9465ba737bd50c"
]
],
"content": "📅 Original date posted:2015-07-30\n📝 Original message:\nSent: Thursday, July 30, 2015 at 4:41 AM\nFrom: \"Rusty Russell\" \u003crusty at rustcorp.com.au\u003e\nTo: \"Christopher Jamthagen\" \u003ccjamthagen at gmx.com\u003e, \"lightning-dev at lists.linuxfoundation.org\" \u003clightning-dev at lists.linuxfoundation.org\u003e\nSubject: Re: [Lightning-dev] Stealing money from a hub?\nChristopher Jamthagen \u003ccjamthagen at gmx.com\u003e writes:\n\u003e\u003e Still trying to get the details right of this protocol. Please correct\n\u003e\u003e me if I am wrong in any of my assumptions below.\n\n\u003e\u003e Assume a payment route: Alice\u003c\u003eBob\u003c\u003eCarol\n\n\u003e\u003e Alice want to pay Carol some amount. Carol gives Alice H(R) and Alice\n\u003e\u003e updates her commitment tx with Bob including the HTLC output and Bob\n\u003e\u003e does the same with Carol.\n\n\u003e OK.\n\n\u003e\u003e Carol witholds R, forcing Bob to broadcast the commitment tx between\n\u003e\u003e Bob and Carol.\n\n\u003e Yep, Carol goes non-responsive. Got it.\n\n\u003e\u003e Carol can now spend the HTLC output because she knows R and thus\n\u003e\u003e revealing it to the world. Alice now also refuses to update the\n\u003e\u003e commitment tx with Bob, forcing Bob to broadcast that commitment tx.\n\n\u003e Poor Bob. Yep.\n\n\u003e\u003e This commitment tx is putting a delay on\n\u003e\u003e Bobs ability to spend the HTLC output (as well as all other outputs to\n\u003e\u003e him), but Alice can spend the HTLC output if the CLTV has expired.\n\n\u003e Indeed, don't ever offer an HTLC less than your delay!\n\nYes, now that you mention it :)\n\nIf we assume that Gregory Maxwell's timestop feature is in use to further delay the expiration of a CSV in the case of full (or near-full) blocks. If this is used, the counterparty can just fill the blocks for a limited amount of time until his CLTV has expired and then take the HTLC output. I guess the time between CSV expiration and CLTV expiration can be adjusted depending on the value being transferred. \n\nWould it be desirable/possible to implement the timestop feature for CLTV as well? That would make the difference between the number of blocks until either expiration the same in case of a block-filling attack. If I'm not mistaken Peter Todds BIP is already merged, but this feature could be implemented with another soft fork.\n\n\u003e\u003e In most examples I have seen, the CLTV is 2 days between Alice and Bob\n\u003e\u003e and 1 day between Bob and Carol, and all CSV delays are 3 days.\n\n\u003e I haven't seen an example which included a CSV delay amount.\n \n \n\u003e As the discussion with Joseph is establishing, the minimum CSV you allow\n\u003e controls the worst-case HTLC you can accept. CSV of a few hours should\n\u003e be OK if you're online all the time. I think...\n\nSpeaking of being online all the time, checking the blockchain is outsourceable, right? So it seems that miners would be the perfect third party to check for cheaters in LN. By offering them a nice chunk of our counterparty's funds as fees, they should be incentiviced enough to keep an extra eye for us on the blockchain.\n\n\u003e Anyone want to do some stats on that? CSV uses the median time of last\n\u003e 11 blocks, so to some extent you can tell the worst case...\n\n\u003e Cheers,\n\u003e Rusty.",
"sig": "e13c5569c93af7648eca90d49228e16b28ddf7948bfe57fefad06970382124de533ce2175c2ca97d4eeb3402745aea9b9a6d59a29a59856f09693a2e60decdfd"
}