Lloyd Fournier [ARCHIVE] on Nostr: 📅 Original date posted:2020-03-06 📝 Original message: Hi Subhra, Afaik, the ...
📅 Original date posted:2020-03-06
📝 Original message:
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200306/41465743/attachment.html>;
📝 Original message:
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200306/41465743/attachment.html>;