{"type":"rich","version":"1.0","author_name":"npub1rmlhmgvxk3p6kv9dgr9tpccm8uh9hejycjm5wag033fvhtpn0jqslw5exr","author_url":"https://nostr.ae/npub1rmlhmgvxk3p6kv9dgr9tpccm8uh9hejycjm5wag033fvhtpn0jqslw5exr","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-10-11\n📝 Original message:\nHey Bastien,\n\nThanks for your reply.\n\nResponses are in-line below:\n\n\u003e Hey John,\n\u003e\n\u003e Thanks for sharing, this is very interesting.\n\u003e\n\u003e There is a good insight here that we can remove the intermediate\n\u003e HTLC-timeout transaction for outgoing payments because we are the\n\u003e origin of that payment (and thus don't need to quickly claim the\n\u003e HTLC on-chain to then relay that failure to a matching incoming HTLC).\n\u003e\n\u003e More generally, you have perfectly identified that most of the\n\u003e complexity of today's transactions come from the need to ensure that\n\u003e a failing/malicious downstream channel doesn't negatively impact\n\u003e honest upstream channels when relaying payments, and that some of this\n\u003e complexity can be lifted when nodes don't relay payments.\n\nThanks!\n\n\u003e However, my main criticism of your proposal is that liquidity isn't free.\n\u003e While your improvements are great from the CLU's point of view, I'm not\n\u003e sure they're acceptable for the DLU. The main (probably only) job of an\n\u003e LSP (DLU in your terminology) is to efficiently allocate their liquidity.\n\u003e In order to do so, they must be able to quickly move liquidity from where\n\u003e it's unused to where it may be better used. That means closely watching\n\u003e the demand for block space and doing on-chain transactions when fees are\n\u003e low (to open/close channels, splice funds in/out [1], make peer swaps [2],\n\u003e etc). With your proposal, DLUs won't be able to quickly move liquidity\n\u003e around, so the only way to make up for this is to charge the CLU for the\n\u003e loss of expected revenue. I'm afraid that the amount DLUs would need to\n\u003e charge CLUs will be prohibitively expensive for most CLUs.\n\u003e\n\u003e I'm curious to get your feedback on that point.\n\nI really appreciate your insight here. I'm just an interested observer who doesn't have experience with creating and deploying Lightning nodes, so I'm sure you have a better understanding of the current costs and trade-offs than I do.\n\nMy understanding of the current Lightning protocol is that users specify a to_self_delay safety parameter which is typically about 2 weeks and that they pay for routing, but not for their partner's cost-of-capital. Is that correct?\n\nIf it is, then when a dedicated user (DLU) partners with a casual user (CLU), the DLU can only move liquidity to another Lightning channel by either:\n1) getting the CLU to sign a cooperative close transaction that enables (or directly implements) the desired movement of funds, or\n2) putting a non-cooperative close transaction on-chain and waiting approximately 2 weeks (based on the to_self_delay parameter set by the CLU) before moving the liquidity.\n\nIn contrast, with the Watchtower-Free (WF) protocol, the DLU could only move liquidity to another Lightning channel by either:\n1) getting the CLU to sign a cooperative close transaction that enables (or directly implements), the desired movement of funds, or\n2) putting a non-cooperative close transaction on-chain and waiting approximately 1-3 months (based on the I_L parameter set by the CLU) before moving the liquidity.\nIn case 1), it would make sense for the DLU to refund the remaining portion of CLU's cost-of-capital pre-payment to the CLU, as that capital is now being made available to the DLU. This was not proposed in the paper, but it should probably be added.\n\nWith this change (namely refunding the remainder of the cost-of-capital pre-payment), it seems like the only disadvantage of the WF protocol to the DLU is the larger delay (1-3 months vs. 2 weeks). Do you feel increasing the delay from 2 weeks to 1 month is prohibitive?\n\nMy intuition is that in the long run, the cost of bitcoin capital will be very low, as it is an inherently deflationary monetary unit (and thus its value should increase with time). If this is correct, the long term cost-of-capital charges should be very low.\n\nWhat are your thoughts on this?\n\nThanks,\nJohn\n\n\u003e Thanks again for sharing, and for the inherited IDs [3] proposal as well!\n\u003e\n\u003e Bastien\n\u003e\n\u003e [1] \u003ca href=\"https://github.com/lightning/bolts/pull/863\"\u003ehttps://github.com/lightning/bolts/pull/863\u003c/a\u003e\n\u003e [2] \u003ca href=\"https://www.peerswap.dev/\"\u003ehttps://www.peerswap.dev/\u003c/a\u003e\n\u003e [3] \u003ca href=\"https://github.com/JohnLaw2/btc-iids\"\u003ehttps://github.com/JohnLaw2/btc-iids\u003c/a\u003e\n\nSent with [Proton Mail](https://proton.me/) secure email.\n\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221012/f0ea0daa/attachment-0001.html\u003e"}