From ziggie1984 at protonmail.com Tue Oct 24 09:12:19 2023 From: ziggie1984 at protonmail.com (ziggie1984) Date: Tue, 24 Oct 2023 09:12:19 +0000 Subject: [Lightning-dev] Removing channel reserve for mobile wallet users In-Reply-To: References: <14lJZzBEaQaRrQN4YACACbTlw912R1iJbjEITJ7Dz3IjdUDhAuSNDBjd9Or8cdf738GYZlRLuaHwcih6EXL9UPxEssPqHOoIY8Myu4908m8=@protonmail.com> Message-ID: <6bgVepRNogd57Nl_xkMG57DeqBJyC2p0wPFs8scf3tqPx0MMMKwE5bqaLjRlflqYucbDcWj2xUHFUZ5b3MsY_SvfkE8Ty-JCFZMvLPPDYNg=@protonmail.com> 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 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: