jlspc [ARCHIVE] on Nostr: 📅 Original date posted:2022-10-11 📝 Original message: Hey Bastien, Thanks for ...
📅 Original date posted:2022-10-11
📝 Original message:
Hey Bastien,
Thanks for your reply.
Responses are in-line below:
> Hey John,
>
> Thanks for sharing, this is very interesting.
>
> There is a good insight here that we can remove the intermediate
> HTLC-timeout transaction for outgoing payments because we are the
> origin of that payment (and thus don't need to quickly claim the
> HTLC on-chain to then relay that failure to a matching incoming HTLC).
>
> More generally, you have perfectly identified that most of the
> complexity of today's transactions come from the need to ensure that
> a failing/malicious downstream channel doesn't negatively impact
> honest upstream channels when relaying payments, and that some of this
> complexity can be lifted when nodes don't relay payments.
Thanks!
> However, my main criticism of your proposal is that liquidity isn't free.
> While your improvements are great from the CLU's point of view, I'm not
> sure they're acceptable for the DLU. The main (probably only) job of an
> LSP (DLU in your terminology) is to efficiently allocate their liquidity.
> In order to do so, they must be able to quickly move liquidity from where
> it's unused to where it may be better used. That means closely watching
> the demand for block space and doing on-chain transactions when fees are
> low (to open/close channels, splice funds in/out [1], make peer swaps [2],
> etc). With your proposal, DLUs won't be able to quickly move liquidity
> around, so the only way to make up for this is to charge the CLU for the
> loss of expected revenue. I'm afraid that the amount DLUs would need to
> charge CLUs will be prohibitively expensive for most CLUs.
>
> I'm curious to get your feedback on that point.
I 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.
My 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?
If 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:
1) getting the CLU to sign a cooperative close transaction that enables (or directly implements) the desired movement of funds, or
2) 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.
In contrast, with the Watchtower-Free (WF) protocol, the DLU could only move liquidity to another Lightning channel by either:
1) getting the CLU to sign a cooperative close transaction that enables (or directly implements), the desired movement of funds, or
2) 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.
In 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.
With 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?
My 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.
What are your thoughts on this?
Thanks,
John
> Thanks again for sharing, and for the inherited IDs [3] proposal as well!
>
> Bastien
>
> [1] <a href="https://github.com/lightning/bolts/pull/863">https://github.com/lightning/bolts/pull/863</a>;
> [2] <a href="https://www.peerswap.dev/">https://www.peerswap.dev/</a>;
> [3] <a href="https://github.com/JohnLaw2/btc-iids">https://github.com/JohnLaw2/btc-iids</a>;
Sent with [Proton Mail](https://proton.me/) secure email.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221012/f0ea0daa/attachment-0001.html>;
📝 Original message:
Hey Bastien,
Thanks for your reply.
Responses are in-line below:
> Hey John,
>
> Thanks for sharing, this is very interesting.
>
> There is a good insight here that we can remove the intermediate
> HTLC-timeout transaction for outgoing payments because we are the
> origin of that payment (and thus don't need to quickly claim the
> HTLC on-chain to then relay that failure to a matching incoming HTLC).
>
> More generally, you have perfectly identified that most of the
> complexity of today's transactions come from the need to ensure that
> a failing/malicious downstream channel doesn't negatively impact
> honest upstream channels when relaying payments, and that some of this
> complexity can be lifted when nodes don't relay payments.
Thanks!
> However, my main criticism of your proposal is that liquidity isn't free.
> While your improvements are great from the CLU's point of view, I'm not
> sure they're acceptable for the DLU. The main (probably only) job of an
> LSP (DLU in your terminology) is to efficiently allocate their liquidity.
> In order to do so, they must be able to quickly move liquidity from where
> it's unused to where it may be better used. That means closely watching
> the demand for block space and doing on-chain transactions when fees are
> low (to open/close channels, splice funds in/out [1], make peer swaps [2],
> etc). With your proposal, DLUs won't be able to quickly move liquidity
> around, so the only way to make up for this is to charge the CLU for the
> loss of expected revenue. I'm afraid that the amount DLUs would need to
> charge CLUs will be prohibitively expensive for most CLUs.
>
> I'm curious to get your feedback on that point.
I 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.
My 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?
If 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:
1) getting the CLU to sign a cooperative close transaction that enables (or directly implements) the desired movement of funds, or
2) 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.
In contrast, with the Watchtower-Free (WF) protocol, the DLU could only move liquidity to another Lightning channel by either:
1) getting the CLU to sign a cooperative close transaction that enables (or directly implements), the desired movement of funds, or
2) 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.
In 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.
With 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?
My 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.
What are your thoughts on this?
Thanks,
John
> Thanks again for sharing, and for the inherited IDs [3] proposal as well!
>
> Bastien
>
> [1] <a href="https://github.com/lightning/bolts/pull/863">https://github.com/lightning/bolts/pull/863</a>;
> [2] <a href="https://www.peerswap.dev/">https://www.peerswap.dev/</a>;
> [3] <a href="https://github.com/JohnLaw2/btc-iids">https://github.com/JohnLaw2/btc-iids</a>;
Sent with [Proton Mail](https://proton.me/) secure email.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221012/f0ea0daa/attachment-0001.html>;