Re: [Lightning-dev] Locking of funds by both parties in HTLC to enforce penalty
So that means if we follow a right to left approach for establishing HTLC i.e. from B to C first then A to B, is there a chance? But I guess that's doesn't sound logical. Also the point raised by you is valid. B can never be punished if it is not possessing the secret at the point of establishment of HTLC. So in that case this becomes a challenge, A to B , B to A atomicity. What if A to B HTLC is established but B to A there is no contract. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Locking of funds by both parties in HTLC to enforce penalty
> Why do we need another HTLC to be established from B to A ? We don't. This wasn't what I was saying. The atomic swap example was just to show that your idea does exist in a different context. An atomic swap can be viewed as a payment A -> B -> A where B switches the currency. > Pardon me if I am wrong but I am still confused why situation 1 will not be possible ? It is possible. In A -> B, A is able to punish B for not revealing secret. The problem is with A -> B -> C, the HTLCs need to be set up from left to right, A can't punish B for not revealing secret because he doesn't know it. B cannot set up the HTLC to C before having the HTLC from A. So it doesn't work -- or at least that's the conventional conclusion. To summarise: A -> B : punishment works A -> B -> A: punishment works A -> B -> C: it can't work (we think) LL On Fri, Mar 6, 2020 at 6:03 PM Subhra Mazumdar < subhra.mazumdar1...@gmail.com> wrote: > Can you send the draft on fair atomic swap? Also the scenario stated in > the pdf you have shared is based on exchange of asset. But here I am not > trying to work on different ledger A to B and B to A. Here it deals with > just simple transfer of funds from A to B. So whatever HTLC A establishes > with B, is it not the case where just one HTLC from A to B is enough? Why > do we need another HTLC to be established from B to A ? To clarify this, > we have two situation - > 1. HTLC A & B (on channel AB): both A and B lock say 0.1 BTC each i.e. 0.2 > BTC > 2. HTLC A&B (on channel AB) : A locks 0.1 BTC, HTLC B&A (on channel BA): B > locks 0.1 BTC > > Pardon me if I am wrong but I am still confused why situation 1 will not > be possible ? > > 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.mazumdar1...@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@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >>> >> > > -- > Yours sincerely, > Subhra Mazumdar. > > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Locking of funds by both parties in HTLC to enforce penalty
Can you send the draft on fair atomic swap? Also the scenario stated in the pdf you have shared is based on exchange of asset. But here I am not trying to work on different ledger A to B and B to A. Here it deals with just simple transfer of funds from A to B. So whatever HTLC A establishes with B, is it not the case where just one HTLC from A to B is enough? Why do we need another HTLC to be established from B to A ? To clarify this, we have two situation - 1. HTLC A & B (on channel AB): both A and B lock say 0.1 BTC each i.e. 0.2 BTC 2. HTLC A&B (on channel AB) : A locks 0.1 BTC, HTLC B&A (on channel BA): B locks 0.1 BTC Pardon me if I am wrong but I am still confused why situation 1 will not be possible ? 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.mazumdar1...@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@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > -- Yours sincerely, Subhra Mazumdar. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Locking of funds by both parties in HTLC to enforce penalty
If you can atomically set up both those penalties atomically then that would be a big breakthrough. It looks impossible. The problem is one will be set up before the other and it is only fair if both are set up at the same time. LL On Fri, Mar 6, 2020 at 5:34 PM Subhra Mazumdar < subhra.mazumdar1...@gmail.com> wrote: > 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.mazumdar1...@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@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >>> >> > > -- > Yours sincerely, > Subhra Mazumdar. > > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Locking of funds by both parties in HTLC to enforce penalty
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.mazumdar1...@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@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > -- Yours sincerely, Subhra Mazumdar. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Locking of funds by both parties in HTLC to enforce penalty
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.mazumdar1...@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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Locking of funds by both parties in HTLC to enforce penalty
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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
