Lloyd Fournier [ARCHIVE] on Nostr: 📅 Original date posted:2020-03-06 📝 Original message: If you can atomically set ...
📅 Original date posted:2020-03-06
📝 Original message:
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.mazumdar1993 at 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 <lloyd.fourn at 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.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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200306/d4a9eca8/attachment-0001.html>;
📝 Original message:
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.mazumdar1993 at 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 <lloyd.fourn at 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.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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200306/d4a9eca8/attachment-0001.html>;