> 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 <lloyd.fo...@gmail.com> > 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
