📅 Original date posted:2022-11-02
📝 Original message:
Good morning John,
> As a result, once the dedicated user decides to splice out some channel
funds, the dedicated user cannot access those funds until some time *after*
the casual user has been online (provided the protocol is trust-free).
The trick here is that the dedicated user *always* has a splice-out tx
available, they don't need to to wait for the casual user to reconnect.
At every update of the channel, the casual user will sign a splice tx
that lets the dedicated user get some of their funds back in case the
casual user goes offline for a long duration. But that splice tx will
indeed be csv-delayed.
Most of the time those splice-out txs will simply be discarded the next
time the channel is updated, but it gives the dedicated user a guarantee
that they're able to get some funds back easily without closing the
channel if they need it.
> Given this observation, what if the protocol were changed so that,
instead of pre-signing a splice transaction, the casual user always checks
in with the dedicated user whenever they check the blockchain? At such a
check-in, if the dedicated user wants to splice out some channel funds,
they send the casual user a splice transaction which splices out some of
the funds to the dedicated user without requiring a to_self delay. The
casual user then signs the splice transaction and returns the signature as
part of the check-in.
Yes, that is something we'll have as well. On the LSP side, we'll most
likely try to get the mobile user to connect and negotiate a splice-out
without any delays. If the mobile user doesn't connect, then we'll use
the pre-signed delayed splice-out we have from the latest channel state
update.
Sorry if this is very hand-wavy, we haven't worked on the details yet,
but at a high-level, this is the kind of flexibility we'd like to have.
> However, if we eventually get to the point where the blockchain is
highly-contested and fees are high, it may no longer be worth paying the
fees to put a splice transaction on-chain unless a large amount of capital
is at stake for a long period of time.
That's true, we're currently using the assumption that fees will be high
but there will be regular opportunities to get txs confirmed at a lower
feerate because of random fluctuations in mempool congestion. If that
doesn't happen, funds will most likely be idle and we won't use those
splices very often.
Cheers,
Bastien
Le lun. 31 oct. 2022 à 01:20, jlspc <jlspc at protonmail.com> a écrit :
> Hi Bastien,
>
> Thanks for your detailed response.
>
> I see how the use of a pre-signed "splice" transaction that allows the dedicated user to obtain some of their capital creates an inherent trade-off between the dedicated user's capital efficiency and the casual user's ability to be offline for an extended period of time.
>
> In order for the use of a pre-signed splice transaction to be safe, the casual user has to check the blockchain and see the splice transaction before it can be spent by the dedicated user (in order to revoke it if needed). As a result, once the dedicated user decides to splice out some channel funds, the dedicated user cannot access those funds until some time *after* the casual user has been online (provided the protocol is trust-free).
>
> Given this observation, what if the protocol were changed so that, instead of pre-signing a splice transaction, the casual user always checks in with the dedicated user whenever they check the blockchain? At such a check-in, if the dedicated user wants to splice out some channel funds, they send the casual user a splice transaction which splices out some of the funds to the dedicated user without requiring a to_self delay. The casual user then signs the splice transaction and returns the signature as part of the check-in.
>
> This approach has a couple potential advantages:
> 1) It allows the dedicated user to splice out funds as soon as the casual user comes online (rather than sometime after the casual user comes online, as shown above). Therefore, the use of capital is made more efficient.
> 2) It allows the splice transaction to pay fees based on the current fee rate, rather than a pre-calculated fee rate.
>
> It does have some potential disadvantages:
> 1) It requires the casual user to stay online long enough to complete the roundtrip of sending a check-in message to the dedicated user, getting the splice message to sign, signing it, and sending the signature back to the dedicated user.
> 2) It assumes that the casual user checks the blockchain themselves, rather than using a watchtower service.
> 3) It requires the dedicated user to decide at the time of the check-in whether or not to perform the splice, as the splice transaction cannot be revoked.
>
> In any case, using a check-in and a non-revokable splice transaction appears to have some advantages in terms of capital efficiency. It's also somewhat more compatible with the WF protocol, as the delay for the dedicated user to obtain spliced-out funds is dependent on the actual time until the casual user next comes online, rather than the worst-case delay until the casual user comes online. This could be a big difference if the casual user is typically online every day, but doesn't want the burden of having to be online every day (or every week). I'm interested in your thoughts on this.
>
> Finally, I understand that the ability to quickly splice out channel funds to improve capital efficiency is critical in the current environment. However, if we eventually get to the point where the blockchain is highly-contested and fees are high, it may no longer be worth paying the fees to put a splice transaction on-chain unless a large amount of capital is at stake for a long period of time.
>
> Regards,
> John
>
>
>
>
> Sent with Proton Mail <https://proton.me/>; secure email.
>
> ------- Original Message -------
> On Monday, October 24th, 2022 at 2:50 AM, Bastien TEINTURIER <
> bastien at acinq.fr> wrote:
>
> 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/20221102/854dbdd6/attachment-0001.html>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-09 13:07:14
in reply to nevent1q…dmdw
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-09 13:07:14Event JSON
{
"id": "8b192849e386616cd4fda8c2ef2579db5f1a4e6aa0afa0d3fe225b596e6e6e7b",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1686316034,
"kind": 1,
"tags": [
[
"e",
"af82929aa01d6fbee8d4c6f7027c872dcbb105b8c22a4647335a977f74a62906",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2022-11-02\n📝 Original message:\nGood morning John,\n\n\u003e As a result, once the dedicated user decides to splice out some channel\nfunds, the dedicated user cannot access those funds until some time *after*\nthe casual user has been online (provided the protocol is trust-free).\n\nThe trick here is that the dedicated user *always* has a splice-out tx\navailable, they don't need to to wait for the casual user to reconnect.\nAt every update of the channel, the casual user will sign a splice tx\nthat lets the dedicated user get some of their funds back in case the\ncasual user goes offline for a long duration. But that splice tx will\nindeed be csv-delayed.\n\nMost of the time those splice-out txs will simply be discarded the next\ntime the channel is updated, but it gives the dedicated user a guarantee\nthat they're able to get some funds back easily without closing the\nchannel if they need it.\n\n\u003e Given this observation, what if the protocol were changed so that,\ninstead of pre-signing a splice transaction, the casual user always checks\nin with the dedicated user whenever they check the blockchain? At such a\ncheck-in, if the dedicated user wants to splice out some channel funds,\nthey send the casual user a splice transaction which splices out some of\nthe funds to the dedicated user without requiring a to_self delay. The\ncasual user then signs the splice transaction and returns the signature as\npart of the check-in.\n\nYes, that is something we'll have as well. On the LSP side, we'll most\nlikely try to get the mobile user to connect and negotiate a splice-out\nwithout any delays. If the mobile user doesn't connect, then we'll use\nthe pre-signed delayed splice-out we have from the latest channel state\nupdate.\n\nSorry if this is very hand-wavy, we haven't worked on the details yet,\nbut at a high-level, this is the kind of flexibility we'd like to have.\n\n\u003e However, if we eventually get to the point where the blockchain is\nhighly-contested and fees are high, it may no longer be worth paying the\nfees to put a splice transaction on-chain unless a large amount of capital\nis at stake for a long period of time.\n\nThat's true, we're currently using the assumption that fees will be high\nbut there will be regular opportunities to get txs confirmed at a lower\nfeerate because of random fluctuations in mempool congestion. If that\ndoesn't happen, funds will most likely be idle and we won't use those\nsplices very often.\n\nCheers,\nBastien\n\nLe lun. 31 oct. 2022 à 01:20, jlspc \u003cjlspc at protonmail.com\u003e a écrit :\n\n\u003e Hi Bastien,\n\u003e\n\u003e Thanks for your detailed response.\n\u003e\n\u003e I see how the use of a pre-signed \"splice\" transaction that allows the dedicated user to obtain some of their capital creates an inherent trade-off between the dedicated user's capital efficiency and the casual user's ability to be offline for an extended period of time.\n\u003e\n\u003e In order for the use of a pre-signed splice transaction to be safe, the casual user has to check the blockchain and see the splice transaction before it can be spent by the dedicated user (in order to revoke it if needed). As a result, once the dedicated user decides to splice out some channel funds, the dedicated user cannot access those funds until some time *after* the casual user has been online (provided the protocol is trust-free).\n\u003e\n\u003e Given this observation, what if the protocol were changed so that, instead of pre-signing a splice transaction, the casual user always checks in with the dedicated user whenever they check the blockchain? At such a check-in, if the dedicated user wants to splice out some channel funds, they send the casual user a splice transaction which splices out some of the funds to the dedicated user without requiring a to_self delay. The casual user then signs the splice transaction and returns the signature as part of the check-in.\n\u003e\n\u003e This approach has a couple potential advantages:\n\u003e 1) It allows the dedicated user to splice out funds as soon as the casual user comes online (rather than sometime after the casual user comes online, as shown above). Therefore, the use of capital is made more efficient.\n\u003e 2) It allows the splice transaction to pay fees based on the current fee rate, rather than a pre-calculated fee rate.\n\u003e\n\u003e It does have some potential disadvantages:\n\u003e 1) It requires the casual user to stay online long enough to complete the roundtrip of sending a check-in message to the dedicated user, getting the splice message to sign, signing it, and sending the signature back to the dedicated user.\n\u003e 2) It assumes that the casual user checks the blockchain themselves, rather than using a watchtower service.\n\u003e 3) It requires the dedicated user to decide at the time of the check-in whether or not to perform the splice, as the splice transaction cannot be revoked.\n\u003e\n\u003e In any case, using a check-in and a non-revokable splice transaction appears to have some advantages in terms of capital efficiency. It's also somewhat more compatible with the WF protocol, as the delay for the dedicated user to obtain spliced-out funds is dependent on the actual time until the casual user next comes online, rather than the worst-case delay until the casual user comes online. This could be a big difference if the casual user is typically online every day, but doesn't want the burden of having to be online every day (or every week). I'm interested in your thoughts on this.\n\u003e\n\u003e Finally, I understand that the ability to quickly splice out channel funds to improve capital efficiency is critical in the current environment. However, if we eventually get to the point where the blockchain is highly-contested and fees are high, it may no longer be worth paying the fees to put a splice transaction on-chain unless a large amount of capital is at stake for a long period of time.\n\u003e\n\u003e Regards,\n\u003e John\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e Sent with Proton Mail \u003chttps://proton.me/\u003e secure email.\n\u003e\n\u003e ------- Original Message -------\n\u003e On Monday, October 24th, 2022 at 2:50 AM, Bastien TEINTURIER \u003c\n\u003e bastien at acinq.fr\u003e wrote:\n\u003e\n\u003e Hi John,\n\u003e\n\u003e \u003e My understanding of the current Lightning protocol is that users specify\n\u003e a to_self_delay safety parameter which is typically about 2 weeks and that\n\u003e they pay for routing, but not for their partner's cost-of-capital. Is that\n\u003e correct?\n\u003e \u003e\n\u003e \u003e If it is, then when a dedicated user (DLU) partners with a casual user\n\u003e (CLU), the DLU can only move liquidity to another Lightning channel by\n\u003e either:\n\u003e \u003e 1) getting the CLU to sign a cooperative close transaction that enables\n\u003e (or directly implements) the desired movement of funds, or\n\u003e \u003e 2) putting a non-cooperative close transaction on-chain and waiting\n\u003e approximately 2 weeks (based on the to_self_delay parameter set by the CLU)\n\u003e before moving the liquidity.\n\u003e\n\u003e That's correct, but that's something we intend to change to let LSPs\n\u003e re-allocate their liquidity more frequently and more efficiently.\n\u003e\n\u003e We don't have a fully specified proposal yet, but by leveraging a\n\u003e mechanism similar to splicing [1], mobile users would pre-sign a\n\u003e transaction that keeps the channel open, but lets the LSP get their\n\u003e balance (or part of it) out non-interactively. This would be used by\n\u003e LSPs if the user isn't using their channel actively enough and the LSP\n\u003e is low on available liquidity for other, more active users.\n\u003e\n\u003e This transaction would need to be revokable and must be delayed, since\n\u003e we still need the user to be able to punish malicious LSPs, but ideally\n\u003e (from the LSP's point of view) that delay should be at most 1 week, which\n\u003e forces users to regularly check the blockchain (which isn't ideal).\n\u003e\n\u003e It really is a trade-off to be able to lower the fees LSPs make users\n\u003e pay for liquidity, because LSPs know they can move it cheaply when it\n\u003e becomes necessary. I can see a future where users chose their trade-off:\n\u003e pay more to be able to go offline for longer periods or pay less but\n\u003e check the blockchain regularly. The same LSP could offer both features,\n\u003e if they're able to price them correctly (which isn't trivial).\n\u003e\n\u003e \u003e My intuition is that in the long run, the cost of bitcoin capital will\n\u003e be very low, as it is an inherently deflationary monetary unit (and thus\n\u003e its value should increase with time). If this is correct, the long term\n\u003e cost-of-capital charges should be very low.\n\u003e\n\u003e I'm not convinced by that...even though the value of capital increases\n\u003e with time, liquidity providers will compete to earn more return on their\n\u003e locked capital. If one liquidity provider is able to use their capital\n\u003e more efficiently than another, they will be able to offer lower prices\n\u003e to their customers to a point that isn't economically viable for the\n\u003e other, less efficient liquidity provider?\n\u003e\n\u003e Since lightning doesn't allow any form of fractional reserve, the total\n\u003e available capital needs to be split between all existing users of the\n\u003e system, which is very inconvenient when trying to onboard a high number\n\u003e of new users.\n\u003e\n\u003e This is very theoretical though, I have absolutely no idea how those\n\u003e dynamics will actually play out, but it will be interesting to watch it\n\u003e unfold.\n\u003e\n\u003e Cheers,\n\u003e Bastien\n\u003e\n\u003e [1] https://github.com/lightning/bolts/pull/863\n\u003e\n\u003e Le mer. 12 oct. 2022 à 02:11, jlspc \u003cjlspc at protonmail.com\u003e a écrit :\n\u003e\n\u003e\u003e\n\u003e\u003e Hey Bastien,\n\u003e\u003e\n\u003e\u003e Thanks for your reply.\n\u003e\u003e\n\u003e\u003e Responses are in-line below:\n\u003e\u003e\n\u003e\u003e \u003e Hey John,\n\u003e\u003e \u003e\n\u003e\u003e \u003e Thanks for sharing, this is very interesting.\n\u003e\u003e \u003e\n\u003e\u003e \u003e There is a good insight here that we can remove the intermediate\n\u003e\u003e \u003e HTLC-timeout transaction for outgoing payments because we are the\n\u003e\u003e \u003e origin of that payment (and thus don't need to quickly claim the\n\u003e\u003e \u003e HTLC on-chain to then relay that failure to a matching incoming HTLC).\n\u003e\u003e \u003e\n\u003e\u003e \u003e More generally, you have perfectly identified that most of the\n\u003e\u003e \u003e complexity of today's transactions come from the need to ensure that\n\u003e\u003e \u003e a failing/malicious downstream channel doesn't negatively impact\n\u003e\u003e \u003e honest upstream channels when relaying payments, and that some of this\n\u003e\u003e \u003e complexity can be lifted when nodes don't relay payments.\n\u003e\u003e\n\u003e\u003e Thanks!\n\u003e\u003e\n\u003e\u003e \u003e However, my main criticism of your proposal is that liquidity isn't free.\n\u003e\u003e \u003e While your improvements are great from the CLU's point of view, I'm not\n\u003e\u003e \u003e sure they're acceptable for the DLU. The main (probably only) job of an\n\u003e\u003e \u003e LSP (DLU in your terminology) is to efficiently allocate their liquidity.\n\u003e\u003e \u003e In order to do so, they must be able to quickly move liquidity from where\n\u003e\u003e \u003e it's unused to where it may be better used. That means closely watching\n\u003e\u003e \u003e the demand for block space and doing on-chain transactions when fees are\n\u003e\u003e \u003e low (to open/close channels, splice funds in/out [1], make peer swaps [2],\n\u003e\u003e \u003e etc). With your proposal, DLUs won't be able to quickly move liquidity\n\u003e\u003e \u003e around, so the only way to make up for this is to charge the CLU for the\n\u003e\u003e \u003e loss of expected revenue. I'm afraid that the amount DLUs would need to\n\u003e\u003e \u003e charge CLUs will be prohibitively expensive for most CLUs.\n\u003e\u003e \u003e\n\u003e\u003e \u003e I'm curious to get your feedback on that point.\n\u003e\u003e\n\u003e\u003e 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.\n\u003e\u003e\n\u003e\u003e 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?\n\u003e\u003e\n\u003e\u003e 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:\n\u003e\u003e 1) getting the CLU to sign a cooperative close transaction that enables (or directly implements) the desired movement of funds, or\n\u003e\u003e 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.\n\u003e\u003e\n\u003e\u003e In contrast, with the Watchtower-Free (WF) protocol, the DLU could only move liquidity to another Lightning channel by either:\n\u003e\u003e 1) getting the CLU to sign a cooperative close transaction that enables (or directly implements), the desired movement of funds, or\n\u003e\u003e 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.\n\u003e\u003e 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.\n\u003e\u003e\n\u003e\u003e 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?\n\u003e\u003e\n\u003e\u003e 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.\n\u003e\u003e\n\u003e\u003e What are your thoughts on this?\n\u003e\u003e\n\u003e\u003e Thanks,\n\u003e\u003e John\n\u003e\u003e\n\u003e\u003e \u003e Thanks again for sharing, and for the inherited IDs [3] proposal as well!\n\u003e\u003e \u003e\n\u003e\u003e \u003e Bastien\n\u003e\u003e \u003e\n\u003e\u003e \u003e [1] \u003ca href=\"https://github.com/lightning/bolts/pull/863\"\u003ehttps://github.com/lightning/bolts/pull/863\u003c/a\u003e\n\u003e\u003e \u003e [2] \u003ca href=\"https://www.peerswap.dev/\"\u003ehttps://www.peerswap.dev/\u003c/a\u003e\n\u003e\u003e \u003e [3] \u003ca href=\"https://github.com/JohnLaw2/btc-iids\"\u003ehttps://github.com/JohnLaw2/btc-iids\u003c/a\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Sent with Proton Mail \u003chttps://proton.me/\u003e secure email.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221102/854dbdd6/attachment-0001.html\u003e",
"sig": "2a7638fee158a8dd6c7ed993eaa59f37ad023721a28647e9f1298fa9e5475bf51549a6c09a3e061f212c8425fa5472caaffb906d1b57a9b6e9247f5c9f3d65ab"
}