We recently removed the reserve for our users in Bitkit (well, down to the dust limit because it doesn't work currently without it).
After I learned more about it, and the reasoning behind the reserve, I realized the design is nonsensical. I fully support Bastien's suggestion for more practical and user-friendly approaches, as the reserve balance causes customer support issues and confusing UX, and Lightning already has too much of that. -- John Carvalho CEO, Synonym.to <http://synonym.to/> On Wed, Oct 18, 2023 at 5:48 PM < lightning-dev-requ...@lists.linuxfoundation.org> wrote: > Send Lightning-dev mailing list submissions to > lightning-dev@lists.linuxfoundation.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > or, via email, send a message with subject or body 'help' to > lightning-dev-requ...@lists.linuxfoundation.org > > You can reach the person managing the list at > lightning-dev-ow...@lists.linuxfoundation.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Lightning-dev digest..." > > > Today's Topics: > > 1. Re: Removing channel reserve for mobile wallet users (SomberNight) > 2. Re: Removing channel reserve for mobile wallet users > (Tony Giorgio) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 18 Oct 2023 15:28:41 +0000 > From: SomberNight <somber.ni...@protonmail.com> > To: Bastien TEINTURIER <bast...@acinq.fr> > Cc: "lightning-dev\\\\\\\\@lists.linuxfoundation.org" > <lightning-dev@lists.linuxfoundation.org> > Subject: Re: [Lightning-dev] Removing channel reserve for mobile > wallet users > Message-ID: > > <w-KgtGRKofF3IAMTXq08nLdZ-ltXvA7x2GHpSzFtzdmDTYujmDnp8YILiylKRoNRKGT0jficMleVVqIBr4R80BWhIyQ3HaWYdBYKXDZROBo=@ > protonmail.com> > > Content-Type: text/plain; charset=utf-8 > > Hi Bastien, > > > [...] The service provider > > cannot steal funds, it only lets them grief their users (at the cost > > of paying on-chain fees and missing out on future routing fees). Also, > > the wallet user can publicly show that the service provider published > > a revoked commitment, which is bad for their reputation. > > I am going off on a tangent here, so this is somewhat off-topic, > but it was not immediately obvious to me how this public attribution > can be done. So I would just like to document it here. > > The wallet user can prove that wallet provider P broadcast an old state: > 1. *a revocation happened*: the user can point to the funding txo > and the mined commitment tx being spent via a revocation path > 2. *the user was one of the participants*: can prove by e.g. signing > with one of the multisig funding keys > 3. *other participant (nodeid) was the provider P*: > (a) if it was a public channel, can show the channel_announcement msg > (b) if it was an unannounced channel, most likely the user has > a channel_update message for the incoming edge, signed by P > (Though this is not guaranteed I guess? bolt-07 just says > P *may* send this channel_update [0]. It is a pain to create > invoices without this, so it is sent in practice.) > 4. *which of the two counterparties cheated*: the user can sign > a message with the revocationpubkey visible onchain that was used > to spend from the old state. > - more generically, the user could prove that they own the txo created > by the revocation > - this step makes point (2) redundant > > I guess the key insight is 3/b, that you can show the > private channel_update. > > Cheers, > ghost43 / SomberNight > > > [0]: > https://github.com/lightning/bolts/blame/4dcc377209509b13cf89a4b91fde7d478f5b46d8/07-routing-gossip.md#L455 > > > > ------- Original Message ------- > On Wednesday, October 18th, 2023 at 13:51, Bastien TEINTURIER < > bast...@acinq.fr> wrote: > > > > Good morning list, > > > > I'd like to discuss the channel reserve requirement, and argue that it > > should be fine to get rid of it for channels between mobile wallet users > > and their service provider. I know, I know, your first reaction will be > > "but this is a security parameter, I don't want to hear about it", but > > please bear with me (and I'll be happy to hear thoughts on why we should > > *not* get rid of this requirement if you still feel strongly about that > > after reading this post). > > > > Let's start by explaining why we generally want a channel reserve. It > > ensures that both peers always have an output in the commit tx, which > > has two important consequences: > > > > - if a malicious node publishes a revoked commitment, they will always > > have some funds in it that the honest node can claim, so they risk > > losing money > > - nodes are disincentivized from force-closing channels, because they > > will need to pay on-chain fees to get their funds back (through a > > 2nd-stage transaction) > > > > I believe those are important properties for channels between normal > > routing nodes that don't provide paid services to each other. If we > > remove the channel reserve, and at one point in time, one of the nodes > > has nothing at stake in the channel, they will be incentivized to > > broadcast a revoked commit tx: if they get away with it, they win some > > money, and otherwise, they don't lose any (because they have nothing at > > stake in the latest channel state). This is particularly true for the > > non-initiator, who doesn't pay the on-chain fees for the commit tx, > > otherwise a malicious initiator would still lose on-chain fees. > > > > Now what are the drawbacks of having a channel reserve? The first one is > > capital efficiency, because this channel reserve is unused liquidity. If > > you are a routing node this is fine, because you actively manage your > > channels to only keep those that earn you enough routing fees. But if > > you are a wallet provider, this is a very different story: you need to > > keep at least one channel open with each of your users. For each of > > these channels, you must maintain a reserve of 1% of the channel > > capacity, even if all the funds are on their side. You thus have unused > > liquidity proportional to the number of users and the total amount of > > sats your users own. This doesn't scale very well. > > > > The second drawback is UX: users look at their channel state to figure > > out how much they can receive off-chain. It's really hard to explain > > why there is a large gap between what they think they should be able > > to receive and what they can actually receive. > > > > Now, why is it ok in this setting to remove the reserve on both sides? > > First of all, the service provider is the one paying the on-chain fees > > for the commit tx (at least that's what we do for Phoenix). That means > > that when publishing a revoked commit tx, even if the service provider > > doesn't have an output in the transaction, they still pay on-chain fees, > > so they lose *something*. For the wallet user, this is ok: they still > > get their funds back using penalty transactions, which doesn't cost > > them more than normal 2nd-stage transactions. The service provider > > cannot steal funds, it only lets them grief their users (at the cost > > of paying on-chain fees and missing out on future routing fees). Also, > > the wallet user can publicly show that the service provider published > > a revoked commitment, which is bad for their reputation. > > > > Removing the reserve on the wallet user's side is a risk that the wallet > > provider takes in order to guarantee a good UX. The user can grief the > > service provider, but the griefing amount is limited. Also, the user has > > paid fees to the wallet provider before that, because they must have > > used the wallet to get into that state. This makes it an acceptable > > trade-off for service providers. > > > > Lastly, we can also argue that LN-penalty without channel reserves is > > similar to LN-symmetry (Eltoo). In Eltoo, a cheating node can always > > publish a previous commitment: the honest node will simply be able to > > replay the latest state on top of that commitment, and the cheating > > node's only penalty is the on-chain fees they paid for that commit tx. > > Here this is the same when the service provider is trying to cheat, > > because they pay the on-chain fees for the commit tx. If this is ok > > for Eltoo, why wouldn't it be ok now? > > > > Cheers, > > Bastien > > > ------------------------------ > > Message: 2 > Date: Wed, 18 Oct 2023 15:46:31 +0000 > From: Tony Giorgio <tonygior...@protonmail.com> > To: Bastien TEINTURIER <bast...@acinq.fr> > Cc: lightning-dev@lists.linuxfoundation.org > Subject: Re: [Lightning-dev] Removing channel reserve for mobile > wallet users > Message-ID: <6d72f52a-72fe-4e0a-b008-3b6029c61...@protonmail.com> > Content-Type: text/plain; charset="utf-8" > > Bastien, > > The main concern on the LSP not keeping a reserve is that it's much easier > for them to steal since the offline concern is on the mobile user. We still > do not yet have reliable watch tower integrations/products to help mitigate > this. Yes, there's reputation, but how does a user go about publishing a > previous commitment? Is that something we should also solve for and expose > to users? > > For dust reserves that still apply: > > > The requirement that `channel_reserve_satoshis` is not considered dust > > according to `dust_limit_satoshis` eliminates cases where all outputs > > would be eliminated as dust. The similar requirements in > > `accept_channel` ensure that both sides' `channel_reserve_satoshis` > > are above both `dust_limit_satoshis`. > > > https://github.com/lightning/bolts/blob/4dcc377209509b13cf89a4b91fde7d478f5b46d8/02-peer-protocol.md?plain=1#L304-L308 > > Tony > > On 10/18/23 9:47 AM, Bastien TEINTURIER wrote: > > > Hey Tony, > > > >> But don't wallets & LSPs already have the option to provide this UX > >> and have been doing it for years? > > > > I'm not sure what other wallets do, but in Phoenix we've only gone half > > way so far: we allow the wallet user to have no reserve, but we require > > the LSP to meet the usual reserve requirements. The goal of my post is > > to argue that we could also remove that requirement for the LSP side > > without adding trust. > > > >> Are you proposing a network wide switch away from reserves or just > >> between mobile wallets and LSPs if they opt in? > > > > I think the channel reserve is useful between routing nodes, because > > they don't have a "service provider" relationship so there is more > > incentive to always try cheating. > > > > I'm only arguing for removing it between wallet users and their LSP > > (partly because LSPs are *not* anonymous nodes who don't care about > > their reputation). > > > >> And what about the dust reserve limit too? > > > > What do you mean by dust reserve limit? > > > > Cheers, > > Bastien > > > > Le mer. 18 oct. 2023 ? 16:33, Tony Giorgio <tonygior...@protonmail.com> > a ?crit : > > > >> Bastien, > >> > >> ACK for this. But don't wallets & LSPs already have the option to > provide this UX and have been doing it for years? Are you proposing a > network wide switch away from reserves or just between mobile wallets and > LSPs if they opt in? And what about the dust reserve limit too? From my > understanding, all of the node implementations allow removing the 1% > reserve requirement now but still keep the dust reserve. > >> > >> Tony Giorgio > >> > >> -------- Original Message -------- > >> On Oct 18, 2023, 8:51?AM, Bastien TEINTURIER < bast...@acinq.fr> wrote: > >> > >>> Good morning list, > >>> > >>> I'd like to discuss the channel reserve requirement, and argue that it > >>> should be fine to get rid of it for channels between mobile wallet > users > >>> and their service provider. I know, I know, your first reaction will be > >>> "but this is a security parameter, I don't want to hear about it", but > >>> please bear with me (and I'll be happy to hear thoughts on why we > should > >>> *not* get rid of this requirement if you still feel strongly about that > >>> after reading this post). > >>> > >>> Let's start by explaining why we generally want a channel reserve. It > >>> ensures that both peers always have an output in the commit tx, which > >>> has two important consequences: > >>> > >>> - if a malicious node publishes a revoked commitment, they will always > >>> have some funds in it that the honest node can claim, so they risk > >>> losing money > >>> - nodes are disincentivized from force-closing channels, because they > >>> will need to pay on-chain fees to get their funds back (through a > >>> 2nd-stage transaction) > >>> > >>> I believe those are important properties for channels between normal > >>> routing nodes that don't provide paid services to each other. If we > >>> remove the channel reserve, and at one point in time, one of the nodes > >>> has nothing at stake in the channel, they will be incentivized to > >>> broadcast a revoked commit tx: if they get away with it, they win some > >>> money, and otherwise, they don't lose any (because they have nothing at > >>> stake in the latest channel state). This is particularly true for the > >>> non-initiator, who doesn't pay the on-chain fees for the commit tx, > >>> otherwise a malicious initiator would still lose on-chain fees. > >>> > >>> Now what are the drawbacks of having a channel reserve? The first one > is > >>> capital efficiency, because this channel reserve is unused liquidity. > If > >>> you are a routing node this is fine, because you actively manage your > >>> channels to only keep those that earn you enough routing fees. But if > >>> you are a wallet provider, this is a very different story: you need to > >>> keep at least one channel open with each of your users. For each of > >>> these channels, you must maintain a reserve of 1% of the channel > >>> capacity, even if all the funds are on their side. You thus have unused > >>> liquidity proportional to the number of users and the total amount of > >>> sats your users own. This doesn't scale very well. > >>> > >>> The second drawback is UX: users look at their channel state to figure > >>> out how much they can receive off-chain. It's really hard to explain > >>> why there is a large gap between what they think they should be able > >>> to receive and what they can actually receive. > >>> > >>> Now, why is it ok in this setting to remove the reserve on both sides? > >>> First of all, the service provider is the one paying the on-chain fees > >>> for the commit tx (at least that's what we do for Phoenix). That means > >>> that when publishing a revoked commit tx, even if the service provider > >>> doesn't have an output in the transaction, they still pay on-chain > fees, > >>> so they lose *something*. For the wallet user, this is ok: they still > >>> get their funds back using penalty transactions, which doesn't cost > >>> them more than normal 2nd-stage transactions. The service provider > >>> cannot steal funds, it only lets them grief their users (at the cost > >>> of paying on-chain fees and missing out on future routing fees). Also, > >>> the wallet user can publicly show that the service provider published > >>> a revoked commitment, which is bad for their reputation. > >>> > >>> Removing the reserve on the wallet user's side is a risk that the > wallet > >>> provider takes in order to guarantee a good UX. The user can grief the > >>> service provider, but the griefing amount is limited. Also, the user > has > >>> paid fees to the wallet provider before that, because they must have > >>> used the wallet to get into that state. This makes it an acceptable > >>> trade-off for service providers. > >>> > >>> Lastly, we can also argue that LN-penalty without channel reserves is > >>> similar to LN-symmetry (Eltoo). In Eltoo, a cheating node can always > >>> publish a previous commitment: the honest node will simply be able to > >>> replay the latest state on top of that commitment, and the cheating > >>> node's only penalty is the on-chain fees they paid for that commit tx. > >>> Here this is the same when the service provider is trying to cheat, > >>> because they pay the on-chain fees for the commit tx. If this is ok > >>> for Eltoo, why wouldn't it be ok now? > >>> > >>> Cheers, > >>> Bastien > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20231018/3dfd9399/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > ------------------------------ > > End of Lightning-dev Digest, Vol 98, Issue 12 > ********************************************* >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
