From subhra.mazumdar1993 at gmail.com Fri Mar 6 06:34:29 2020 From: subhra.mazumdar1993 at gmail.com (Subhra Mazumdar) Date: Fri, 6 Mar 2020 12:04:29 +0530 Subject: [Lightning-dev] Locking of funds by both parties in HTLC to enforce penalty In-Reply-To: References: Message-ID: But wont the decision of penalty be based on what incoming contract expects from a node ? Suppose there is a contract between A and B and then B and C, where A wants to transfer money to C. So if it is the case that A impose penalty on B using its local HTLC, won't B put the same clause on C as well so that in case C misbehaves it is able to spool out the penalty for the rest of the path from C itself ? On Fri, Mar 6, 2020 at 12:00 PM Lloyd Fournier wrote: > Hi Subhra, > > Afaik, the only problem is the one you identified, it doesn't work across > multiple hops but only for the final hop. This penalty idea is the basis > for doing atomc swaps fairly: > https://coblox.tech/docs/financial_crypto19.pdf > > LL > On Fri, Mar 6, 2020 at 4:58 PM Subhra Mazumdar < > subhra.mazumdar1993 at gmail.com> wrote: > >> Hi, >> I was reading the paper by Poon and Dryja on Bitcoin Lightning >> Network and was going through the construction of HTLC. Suppose 2 parties A >> and B have a channel with each party locking 0.5 BTC. Suppose A wants to >> transfer 0.1 BTC to B contingent to the knowledge of R : H=h(R) produced >> within a locktime of say t days. So the script output for A is - >> 1. 0.4 BTC to A >> 2. 0.5 BTC to B >> 3. 0.1 BTC locked in HTLC between A & B. >> Why we cannot set the terms as say 0.4 BTC to A, 0.2 BTC to B and 0.4 BTC >> to HTLC, where HTLC output can follow either of the paths - If B produces R >> within t days then it gets back 0.4 BTC else after t days A can broadcast >> with 0.4 BTC going to the A? This prevents B from not responding (and >> induce possibly griefing attack across a longer path by withholding the >> solution) since it will lose out 0.3 BTC. What can be the problem if the >> terms of HTLC itself tries to enforce a penalty on the counterparty? >> >> -- >> Yours sincerely, >> Subhra Mazumdar. >> >> _______________________________________________ >> Lightning-dev mailing list >> Lightning-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > -- Yours sincerely, Subhra Mazumdar. -------------- next part -------------- An HTML attachment was scrubbed... URL: