📅 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>;
Lloyd Fournier [ARCHIVE] /
npub1kh…y05yp
2023-06-09 12:59:12
in reply to nevent1q…8nwf
Author Public Key
npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05ypPublished at
2023-06-09 12:59:12Event JSON
{
"id": "51482ca15de13b9583d8749ace4a8b18b508f2cd3cb586a260449893a0431809",
"pubkey": "b5ff7c704f90e4eebfa414c0a017a84544c32586a1bd2fc86c74c2914d03c25e",
"created_at": 1686315552,
"kind": 1,
"tags": [
[
"e",
"41eb27a7e0ef742b5e7fead99779784c731238151c39031c209548edb79f0a60",
"",
"root"
],
[
"e",
"cbdf3268c0ba2f611e1fde668e6decfb9f7ca7fdfe14550d7fc43691e3feb63e",
"",
"reply"
],
[
"p",
"84dde5d7bce077e7cd64c91dc102677e13acc29126ce3f889bb9d2b2f81b200a"
]
],
"content": "📅 Original date posted:2020-03-06\n📝 Original message:\nHi Subhra,\n\nAfaik, the only problem is the one you identified, it doesn't work across\nmultiple hops but only for the final hop. This penalty idea is the basis\nfor doing atomc swaps fairly:\nhttps://coblox.tech/docs/financial_crypto19.pdf\n\nLL\nOn Fri, Mar 6, 2020 at 4:58 PM Subhra Mazumdar \u003c\nsubhra.mazumdar1993 at gmail.com\u003e wrote:\n\n\u003e Hi,\n\u003e I was reading the paper by Poon and Dryja on Bitcoin Lightning\n\u003e Network and was going through the construction of HTLC. Suppose 2 parties A\n\u003e and B have a channel with each party locking 0.5 BTC. Suppose A wants to\n\u003e transfer 0.1 BTC to B contingent to the knowledge of R : H=h(R) produced\n\u003e within a locktime of say t days. So the script output for A is -\n\u003e 1. 0.4 BTC to A\n\u003e 2. 0.5 BTC to B\n\u003e 3. 0.1 BTC locked in HTLC between A \u0026 B.\n\u003e Why we cannot set the terms as say 0.4 BTC to A, 0.2 BTC to B and 0.4 BTC\n\u003e to HTLC, where HTLC output can follow either of the paths - If B produces R\n\u003e within t days then it gets back 0.4 BTC else after t days A can broadcast\n\u003e with 0.4 BTC going to the A? This prevents B from not responding (and\n\u003e induce possibly griefing attack across a longer path by withholding the\n\u003e solution) since it will lose out 0.3 BTC. What can be the problem if the\n\u003e terms of HTLC itself tries to enforce a penalty on the counterparty?\n\u003e\n\u003e --\n\u003e Yours sincerely,\n\u003e Subhra Mazumdar.\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200306/41465743/attachment.html\u003e",
"sig": "aa4408c15cd0fd884a3aee5edcb5ba6cc36428dbe858be205eaca5551d6e1cba612aa4aa4c3b57382b234e92604cdc0d679456e07c49a4e908769eb81e1b69e0"
}