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