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 <bast...@acinq.fr>
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 <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
