📅 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>;
Lloyd Fournier [ARCHIVE] /
npub1kh…y05yp
2023-06-09 12:59:12
in reply to nevent1q…uuvc
Author Public Key
npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05ypPublished at
2023-06-09 12:59:12Event JSON
{
"id": "8589b066a21b02ec48b2b4122586a72d68f4c208af204667b405a037acc56d6a",
"pubkey": "b5ff7c704f90e4eebfa414c0a017a84544c32586a1bd2fc86c74c2914d03c25e",
"created_at": 1686315552,
"kind": 1,
"tags": [
[
"e",
"41eb27a7e0ef742b5e7fead99779784c731238151c39031c209548edb79f0a60",
"",
"root"
],
[
"e",
"e86c582f35d5f7fa65ce4e8242cfb75eff004e5d8926041693955598c3d3d978",
"",
"reply"
],
[
"p",
"84dde5d7bce077e7cd64c91dc102677e13acc29126ce3f889bb9d2b2f81b200a"
]
],
"content": "📅 Original date posted:2020-03-06\n📝 Original message:\nIf you can atomically set up both those penalties atomically then that\nwould be a big breakthrough. It looks impossible. The problem is one will\nbe set up before the other and it is only fair if both are set up at the\nsame time.\n\nLL\n\nOn Fri, Mar 6, 2020 at 5:34 PM Subhra Mazumdar \u003c\nsubhra.mazumdar1993 at gmail.com\u003e wrote:\n\n\u003e But wont the decision of penalty be based on what incoming contract\n\u003e expects from a node ? Suppose there is a contract between A and B and then\n\u003e B and C, where A wants to transfer money to C. So if it is the case that A\n\u003e impose penalty on B using its local HTLC, won't B put the same clause on C\n\u003e as well so that in case C misbehaves it is able to spool out the penalty\n\u003e for the rest of the path from C itself ?\n\u003e\n\u003e On Fri, Mar 6, 2020 at 12:00 PM Lloyd Fournier \u003clloyd.fourn at gmail.com\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e Hi Subhra,\n\u003e\u003e\n\u003e\u003e Afaik, the only problem is the one you identified, it doesn't work across\n\u003e\u003e multiple hops but only for the final hop. This penalty idea is the basis\n\u003e\u003e for doing atomc swaps fairly:\n\u003e\u003e https://coblox.tech/docs/financial_crypto19.pdf\n\u003e\u003e\n\u003e\u003e LL\n\u003e\u003e On Fri, Mar 6, 2020 at 4:58 PM Subhra Mazumdar \u003c\n\u003e\u003e subhra.mazumdar1993 at gmail.com\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e Hi,\n\u003e\u003e\u003e I was reading the paper by Poon and Dryja on Bitcoin Lightning\n\u003e\u003e\u003e Network and was going through the construction of HTLC. Suppose 2 parties A\n\u003e\u003e\u003e and B have a channel with each party locking 0.5 BTC. Suppose A wants to\n\u003e\u003e\u003e transfer 0.1 BTC to B contingent to the knowledge of R : H=h(R) produced\n\u003e\u003e\u003e within a locktime of say t days. So the script output for A is -\n\u003e\u003e\u003e 1. 0.4 BTC to A\n\u003e\u003e\u003e 2. 0.5 BTC to B\n\u003e\u003e\u003e 3. 0.1 BTC locked in HTLC between A \u0026 B.\n\u003e\u003e\u003e Why we cannot set the terms as say 0.4 BTC to A, 0.2 BTC to B and 0.4\n\u003e\u003e\u003e BTC to HTLC, where HTLC output can follow either of the paths - If B\n\u003e\u003e\u003e produces R within t days then it gets back 0.4 BTC else after t days A can\n\u003e\u003e\u003e broadcast with 0.4 BTC going to the A? This prevents B from not responding\n\u003e\u003e\u003e (and induce possibly griefing attack across a longer path by withholding\n\u003e\u003e\u003e the solution) since it will lose out 0.3 BTC. What can be the problem if\n\u003e\u003e\u003e the terms of HTLC itself tries to enforce a penalty on the counterparty?\n\u003e\u003e\u003e\n\u003e\u003e\u003e --\n\u003e\u003e\u003e Yours sincerely,\n\u003e\u003e\u003e Subhra Mazumdar.\n\u003e\u003e\u003e\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e Lightning-dev mailing list\n\u003e\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\n\u003e --\n\u003e Yours sincerely,\n\u003e Subhra Mazumdar.\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200306/d4a9eca8/attachment-0001.html\u003e",
"sig": "875191d7b5129ca1d0444be7b0554e142e0c6ef9220c97cb58087762b8d11f33dd0bf1253840aab010bd54fb5ebf1bab1ddab5409c7c733ad6a56d79095bcebe"
}