From benjamin.l.cordes at gmail.com Thu Jul 30 08:17:55 2015 From: benjamin.l.cordes at gmail.com (Benjamin) Date: Thu, 30 Jul 2015 10:17:55 +0200 Subject: [Lightning-dev] Stealing money from a hub? In-Reply-To: <87oaiunz8j.fsf@rustcorp.com.au> References: <87oaiunz8j.fsf@rustcorp.com.au> Message-ID: >> Still trying to get the details right of this protocol. Me too, but I have some more basic problems. >> Assume a payment route: Alice<>Bob<>Carol * how does Alice know Bob and Carol? In Bitcoin there needs to be out-of-band key exchange, but there is no ID attached to the keys. The concept of a hub seems to imply either use of standard PKI or Web-of-trust. Both have big problems when it comes to large, frequent financial transactions. * why should Bob even participate in this transaction? Currently I don't see that incentives are described. That is a fundamental part of Bitcoin and makes network based intermediation possible (Alice <> computer network with N nodes <> Carol). From the point of view of a node, Bitcoin does not have a scalability issue. The only concern of the node is to maximize knowable profit. On Thu, Jul 30, 2015 at 4:41 AM, Rusty Russell wrote: > 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. > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: