Re: [Lightning-dev] Removing channel reserve for mobile wallet users
I just checked some implementations, lnd for example currently checks that the reserve is at least the dust limit [0], which seems reasonable. But with the proposed protocol update this has to change. Looking forward to the Blip. Ziggie [0] https://github.com/lightningnetwork/lnd/blob/master/lnwallet/reservation.go#L815-L817 --- Original Message --- On Tuesday, October 24th, 2023 at 10:09, Bastien TEINTURIER wrote: > Hi Ziggie, > >> Do we want to add this via a Blip? > > Sure, I'll open a PR to the bLIP repository, that would be useful. > >> (well, down to the dust limit because it doesn't work currently without it). >> I think this behaviour could/should be fixed, have you already reported the >> issue? > > I'm really unsure what "it doesn't work currently without it" refers to > here. Is that an implementation-specific issue? If we remove the channel > reserve, there's no reason to care about the dust limit. > > Cheers, > Bastien > > Le lun. 23 oct. 2023 à 23:16, ziggie1984 a écrit : > >> Hi Bastien, hi list, >> >> Thank you for taking both perspectives on this topic. I am in favour of >> introducing the 0-channel reserve option into the protocol (via an optional >> feature bit). Do we want to add this via a Blip? >> Although it makes sense to have this reserve when you are running a routing >> node, it would be neat to at least have the option to open zero-reserve >> channels (pops up from time to time in noderunner groups). Of course this >> would have to be restricted via a channel interceptor so that not only by >> signaling zero-reserve feature bit, you would be accepting those channels >> (same approach as for zero-conf channels maybe, but thats implementation >> related imo). >> >> I find it also useful to include informations how one could prove possible >> cheating attacks in the spec/blip (as SomberNight already elaborated). >> >>> We recently removed the reserve for our users in Bitkit (well, down to the >>> dust limit because it doesn't work currently without it). >> >> I think this behaviour could/should be fixed, have you already reported the >> issue? >> >> Cheers, >> ziggie >> >> --- Original Message --- >> On Wednesday, October 18th, 2023 at 15:51, Bastien TEINTURIER >> 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
Re: [Lightning-dev] Removing channel reserve for mobile wallet users
Hi Ziggie, > Do we want to add this via a Blip? Sure, I'll open a PR to the bLIP repository, that would be useful. > (well, down to the dust limit because it doesn't work currently without it). > I think this behaviour could/should be fixed, have you already reported the issue? I'm really unsure what "it doesn't work currently without it" refers to here. Is that an implementation-specific issue? If we remove the channel reserve, there's no reason to care about the dust limit. Cheers, Bastien Le lun. 23 oct. 2023 à 23:16, ziggie1984 a écrit : > Hi Bastien, hi list, > > Thank you for taking both perspectives on this topic. I am in favour of > introducing the 0-channel reserve option into the protocol (via an optional > feature bit). Do we want to add this via a Blip? > Although it makes sense to have this reserve when you are running a > routing node, it would be neat to at least have the option to open > zero-reserve channels (pops up from time to time in noderunner groups). Of > course this would have to be restricted via a channel interceptor so that > not only by signaling zero-reserve feature bit, you would be accepting > those channels (same approach as for zero-conf channels maybe, but thats > implementation related imo). > > I find it also useful to include informations how one could prove possible > cheating attacks in the spec/blip (as SomberNight already elaborated). > > We recently removed the reserve for our users in Bitkit (well, down to the > dust limit because it doesn't work currently without it). > > I think this behaviour could/should be fixed, have you already reported > the issue? > > Cheers, > ziggie > > --- Original Message --- > On Wednesday, October 18th, 2023 at 15: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,
Re: [Lightning-dev] Removing channel reserve for mobile wallet users
Hi Bastien, hi list, Thank you for taking both perspectives on this topic. I am in favour of introducing the 0-channel reserve option into the protocol (via an optional feature bit). Do we want to add this via a Blip? Although it makes sense to have this reserve when you are running a routing node, it would be neat to at least have the option to open zero-reserve channels (pops up from time to time in noderunner groups). Of course this would have to be restricted via a channel interceptor so that not only by signaling zero-reserve feature bit, you would be accepting those channels (same approach as for zero-conf channels maybe, but thats implementation related imo). I find it also useful to include informations how one could prove possible cheating attacks in the spec/blip (as SomberNight already elaborated). > We recently removed the reserve for our users in Bitkit (well, down to the > dust limit because it doesn't work currently without it). I think this behaviour could/should be fixed, have you already reported the issue? Cheers, ziggie --- Original Message --- On Wednesday, October 18th, 2023 at 15:51, Bastien TEINTURIER 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
Re: [Lightning-dev] Removing channel reserve for mobile wallet users
Hi Tony, Kulpreet, > 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? If you're assuming that your non-custodial wallet is unable to react to revoked commitments, then you have a lot of other problems in your trust model anyway? Note that the important delay here is the `to_self_delay` parameter, which is usually set to two weeks. Your phone only needs to be online once every two weeks to detect the revoked commit and react to it. Mobile wallets should all run frequent background jobs to perform those checks, and warn the user with a notification if they've been unable to get enough CPU time to run those checks. That's what Phoenix does. > For dust reserves that still apply: That doesn't apply here, this goes away when removing the reserve requirement. There will always be at least one output since the channel total capacity stays (much) greater than dust. > From my nascent understanding this will require differentiating > between types of participants. > Will the above then add complications of participant type into the > protocol at the time of creating commitments, forwarding HTLCs and > also finding routes? This doesn't add anything new, this distinction already exists today. It doesn't add any complication to the protocol either, LSPs simply add extensions for additional features. Negotiating 0-reserve is as simple as setting a feature bit or adding a TLV to existing messages. Cheers, Bastien Le jeu. 19 oct. 2023 à 09:28, Kulpreet Singh a écrit : > From my nascent understanding this will require differentiating between > types of participants. > > Will the above then add complications of participant type into the > protocol at the time of creating commitments, forwarding HTLCs and also > finding routes? > > -kp > > --- Original Message --- > On Wednesday, October 18th, 2023 at 3:51 PM, 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 >
Re: [Lightning-dev] Removing channel reserve for mobile wallet users
From my nascent understanding this will require differentiating between types of participants. Will the above then add complications of participant type into the protocol at the time of creating commitments, forwarding HTLCs and also finding routes? -kp --- Original Message --- On Wednesday, October 18th, 2023 at 3:51 PM, Bastien TEINTURIER 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___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Removing channel reserve for mobile wallet users
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 + > From: SomberNight > To: Bastien TEINTURIER > Cc: "lightning-dev@lists.linuxfoundation.org" > > Subject: Re: [Lightning-dev] Removing channel reserve for mobile > wallet users > Message-ID: > > 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 fund
Re: [Lightning-dev] Removing channel reserve for mobile wallet users
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 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
Re: [Lightning-dev] Removing channel reserve for mobile wallet users
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 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
Re: [Lightning-dev] Removing channel reserve for mobile wallet users
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 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
Re: [Lightning-dev] Removing channel reserve for mobile wallet users
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 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, >
