📅 Original date posted:2020-03-06 📝 Original message: But ...

2023-06-09T12:59:12Z

In reply to nevent1q…s089
_________________________

📅 Original date posted:2020-03-06
📝 Original message:
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/85f11fb8/attachment.html>;

📅 Original date posted:2020-03-06 📝 Original message: Hi, I ...

2023-06-09T12:59:11Z

In reply to nevent1q…hpyx
_________________________

📅 Original date posted:2020-03-06
📝 Original message:
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200306/6350cd37/attachment.html>;

Nostr notes by Subhra Mazumdar [ARCHIVE]

📅 Original date posted:2020-03-06 📝 Original message: But ...

📅 Original date posted:2020-03-06 📝 Original message: Hi, I ...