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
