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,
> Bastien
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
