Bastien TEINTURIER [ARCHIVE] on Nostr: 📅 Original date posted:2022-10-24 📝 Original message: Hi John, > My ...
📅 Original date posted:2022-10-24
📝 Original message:
Hi John,
> 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.
That's correct, but that's something we intend to change to let LSPs
re-allocate their liquidity more frequently and more efficiently.
We don't have a fully specified proposal yet, but by leveraging a
mechanism similar to splicing [1], mobile users would pre-sign a
transaction that keeps the channel open, but lets the LSP get their
balance (or part of it) out non-interactively. This would be used by
LSPs if the user isn't using their channel actively enough and the LSP
is low on available liquidity for other, more active users.
This transaction would need to be revokable and must be delayed, since
we still need the user to be able to punish malicious LSPs, but ideally
(from the LSP's point of view) that delay should be at most 1 week, which
forces users to regularly check the blockchain (which isn't ideal).
It really is a trade-off to be able to lower the fees LSPs make users
pay for liquidity, because LSPs know they can move it cheaply when it
becomes necessary. I can see a future where users chose their trade-off:
pay more to be able to go offline for longer periods or pay less but
check the blockchain regularly. The same LSP could offer both features,
if they're able to price them correctly (which isn't trivial).
> 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.
I'm not convinced by that...even though the value of capital increases
with time, liquidity providers will compete to earn more return on their
locked capital. If one liquidity provider is able to use their capital
more efficiently than another, they will be able to offer lower prices
to their customers to a point that isn't economically viable for the
other, less efficient liquidity provider?
Since lightning doesn't allow any form of fractional reserve, the total
available capital needs to be split between all existing users of the
system, which is very inconvenient when trying to onboard a high number
of new users.
This is very theoretical though, I have absolutely no idea how those
dynamics will actually play out, but it will be interesting to watch it
unfold.
Cheers,
Bastien
[1] https://github.com/lightning/bolts/pull/863
Le mer. 12 oct. 2022 à 02:11, jlspc <jlspc at protonmail.com> a écrit :
>
> 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/20221024/c1713a2e/attachment.html>;
📝 Original message:
Hi John,
> 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.
That's correct, but that's something we intend to change to let LSPs
re-allocate their liquidity more frequently and more efficiently.
We don't have a fully specified proposal yet, but by leveraging a
mechanism similar to splicing [1], mobile users would pre-sign a
transaction that keeps the channel open, but lets the LSP get their
balance (or part of it) out non-interactively. This would be used by
LSPs if the user isn't using their channel actively enough and the LSP
is low on available liquidity for other, more active users.
This transaction would need to be revokable and must be delayed, since
we still need the user to be able to punish malicious LSPs, but ideally
(from the LSP's point of view) that delay should be at most 1 week, which
forces users to regularly check the blockchain (which isn't ideal).
It really is a trade-off to be able to lower the fees LSPs make users
pay for liquidity, because LSPs know they can move it cheaply when it
becomes necessary. I can see a future where users chose their trade-off:
pay more to be able to go offline for longer periods or pay less but
check the blockchain regularly. The same LSP could offer both features,
if they're able to price them correctly (which isn't trivial).
> 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.
I'm not convinced by that...even though the value of capital increases
with time, liquidity providers will compete to earn more return on their
locked capital. If one liquidity provider is able to use their capital
more efficiently than another, they will be able to offer lower prices
to their customers to a point that isn't economically viable for the
other, less efficient liquidity provider?
Since lightning doesn't allow any form of fractional reserve, the total
available capital needs to be split between all existing users of the
system, which is very inconvenient when trying to onboard a high number
of new users.
This is very theoretical though, I have absolutely no idea how those
dynamics will actually play out, but it will be interesting to watch it
unfold.
Cheers,
Bastien
[1] https://github.com/lightning/bolts/pull/863
Le mer. 12 oct. 2022 à 02:11, jlspc <jlspc at protonmail.com> a écrit :
>
> 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/20221024/c1713a2e/attachment.html>;