Hi Bastien,
> [...] 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.
I am going off on a tangent here, so this is somewhat off-topic,
but it was not immediately obvious to me how this public attribution
can be done. So I would just like to document it here.
The wallet user can prove that wallet provider P broadcast an old state:
1. *a revocation happened*: the user can point to the funding txo
and the mined commitment tx being spent via a revocation path
2. *the user was one of the participants*: can prove by e.g. signing
with one of the multisig funding keys
3. *other participant (nodeid) was the provider P*:
(a) if it was a public channel, can show the channel_announcement msg
(b) if it was an unannounced channel, most likely the user has
a channel_update message for the incoming edge, signed by P
(Though this is not guaranteed I guess? bolt-07 just says
P *may* send this channel_update [0]. It is a pain to create
invoices without this, so it is sent in practice.)
4. *which of the two counterparties cheated*: the user can sign
a message with the revocationpubkey visible onchain that was used
to spend from the old state.
- more generically, the user could prove that they own the txo created
by the revocation
- this step makes point (2) redundant
I guess the key insight is 3/b, that you can show the
private channel_update.
Cheers,
ghost43 / SomberNight
[0]:
https://github.com/lightning/bolts/blame/4dcc377209509b13cf89a4b91fde7d478f5b46d8/07-routing-gossip.md#L455
------- Original Message -------
On Wednesday, October 18th, 2023 at 13: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
