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 <ziggie1...@protonmail.com> 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, 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
