From rusty at rustcorp.com.au Thu Jul 30 02:41:32 2015 From: rusty at rustcorp.com.au (Rusty Russell) Date: Thu, 30 Jul 2015 12:11:32 +0930 Subject: [Lightning-dev] Stealing money from a hub? In-Reply-To: References: Message-ID: <87oaiunz8j.fsf@rustcorp.com.au> Christopher Jamthagen 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.