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