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.
>
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
