Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2021-02-12 📝 Original message: Hi Antoine, That said, ...
📅 Original date posted:2021-02-12
📝 Original message:
Hi Antoine,
That said, routing nodes might still include the risk of hitting the chain
> in the computation of their `hodl_fee_rate` and the corresponding cost of
> having onchain timelocked funds.
>
Yes, that could be another reason to define `hodl_fee_rate` as a base fee
rate plus a component that is proportional to the amount. As mentioned in
my initial email, the base fee can be used to cover the cost of occupying
an htlc slot (which can be a significant factor for a large wumbo channel).
The risk of hitting the chain that you mention can be factored into this
base part as well. The hold fee rate would then be defined in the form (2
sat + 1%) per minute.
> Given that HTLC deltas are decreasing along the path, it's more likely
> that `hodl_fee_rate` will be decreasing along the path. Even in case of
> lawfully solved hodl HTLC, routing nodes might be at loss for having paid a
> higher hold_fee on their upstream link than received on the downstream one.
>
> Is assuming increasing `hodl_fee_rate` along a payment path at odds with
> the ordering of timelocks ?
>
I don't think it is. There is indeed a time lock delta in case htlcs need
to be settled on-chain. But in the happy offchain scenario, the added (wall
clock) delay of a hop is tiny. So yes, they get paid from downstream a few
seconds less in hold fees than what they need to pay upstream, but I think
this is insignificant compared to the total compensation that they are
getting (which is based on the grace period that is advertised). To be
clear, for the calculation of the hold fee, it is the wall clock time that
is used and not the block height.
> > But this would also mean that anyone can send out an htlc and collect
> hold fees unconditionally. Therefore routing nodes advertise on the network
> their `hold_grace_period`. When routing nodes accept an htl> to forward,
> they're willing to pay hold fees for it. But only if they added a delay
> greater than `hold_grace_period` for relaying the payment and its response.
> If they relayed in a timely fashion, they exp> ect the sender of the htlc
> to cover those costs themselves. If the sender is also a routing node, the
> sender should expect the node before them to cover it. Of course, routing
> nodes can't be trusted. So in> practice we can just as well assume that
> they'll always try to claim from the prior node the maximum amount in
> compensation.
>
> Assuming `hodl_fee_rate` are near-similar along the payment path, you have
> a concern when the HTLC settlement happens at period N on the outgoing link
> and at period N+1 on the incoming link due to clock differences. In this
> case, a routing node will pay a higher `hodl_fee_rate` than received.
>
> I think this is okay, that's an edge case, only leaking a few sats.
>
Is this the same concern as above or slightly different? Or do you mean
clock differences between the endpoints of a channel? For that, I'd think
that there needs to be some tolerance to smooth out disagreements. But yes,
in general as long as a node is getting a positive amount, it is probably
okay to tolerate a few rounding errors here and there.
> A more concerning one is when the HTLC settlement happens at period N on
> the outgoing link and your incoming counterparty goes offline. According to
> the HTLC relay contract, the `hodl_fee_rate` will be inflated until the
> counterparty goes back online and thus the routing node is at loss. And
> going offline is a really lawful behavior for mobile clients, even further
> if you consider mailbox-style of HTLC delivery (e.g Lightning Rod). You
> can't simply label such counterparty as malicious.
>
> And I don't think counterparties can trust themselves about their onliness
> to suspend the `hodl_fee_rate` inflation. Both sides have an interest to
> equivocate, the HTLC sender to gain a higher fee, the HTLC relayer to save
> the fee while having received one on the incoming link ?
>
Yes, that is a good point. But I do think that it is reasonable that a node
that can go offline doesn't charge a hodl fee. Those nodes aren't generally
forwarding htlcs anyway, so it would just be for their own outgoing
payments. Without charging a hodl fee for outgoing payments, they risk that
their channel peer delays the htlc for free. So they should choose their
peers carefully. It seems that at the moment mobile nodes are often
connected to a known LSP already, so this may not be a real problem. The
policies for a channel can be asymmetric with the mobile node not charging
hold fees for its outgoing htlcs to the LSP, while the LSP does charge hold
fees for htlcs that its forwards to the mobile node.
For the mailbox scenario, I think it is fair that someone is going to pay
for all those locked htlcs along the route. If the LSP decides to hold the
htlc until the destination comes online, they need to find a way to get the
mailbox bill paid.
All of this indeed also implies that nodes that do charge hold fees, need
to make sure to stay online. Otherwise peers may close channels with them
because they are unreliable and charging for their own outage.
> > Even though the proposal above is not fundamentally different from what
> was known already, I do think that it adds the flexibility that we need to
> not take a step back in terms of functionality (fair prici> ng for hodl
> invoices and its applications). Plus that it simplifies the parameter set.
>
> Minding the concerns raised above, I think this proposal is an improvement
> and would merit a specification draft, at least to ease further reasoning
> on its economic and security soundness. As a side-note, we're working
> further on Stake Certificates, which I believe is better for long-term
> network economics by not adding a new fee burden on payments. We should be
> careful to not economically outlaw micropayments.
>
Yes, we should be careful not to outlaw micropayments. But I don't think
the hold fees as described above do this. Because the fees are modeled as
close to the real costs as possible, it can only be fair? Tiny amounts that
settle quickly should need only very small hold fees. But if the tiny
amount gets stuck for a week and occupies an htlc slot in each of its 25
hops through multi-btc wumbo channels, yes, than it should be costly?
> If we think channel jamming is concerning enough in the short-term, we can
> deploy a bidirectional upfront payment-style of proposal now and consider a
> better solution when it's technically mature.
>
It remains unclear how much time we still have to fix this. Already today
there are nodes on the network that benefit from short interruptions of
large channel sets between the bigger nodes. During those interruptions,
they provide a fallback route at a premium price. It is not difficult to
come up with actions that happen to make those disruptions more likely to
happen. I wouldn't take too many chances with this.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210212/835761e2/attachment-0001.html>;
📝 Original message:
Hi Antoine,
That said, routing nodes might still include the risk of hitting the chain
> in the computation of their `hodl_fee_rate` and the corresponding cost of
> having onchain timelocked funds.
>
Yes, that could be another reason to define `hodl_fee_rate` as a base fee
rate plus a component that is proportional to the amount. As mentioned in
my initial email, the base fee can be used to cover the cost of occupying
an htlc slot (which can be a significant factor for a large wumbo channel).
The risk of hitting the chain that you mention can be factored into this
base part as well. The hold fee rate would then be defined in the form (2
sat + 1%) per minute.
> Given that HTLC deltas are decreasing along the path, it's more likely
> that `hodl_fee_rate` will be decreasing along the path. Even in case of
> lawfully solved hodl HTLC, routing nodes might be at loss for having paid a
> higher hold_fee on their upstream link than received on the downstream one.
>
> Is assuming increasing `hodl_fee_rate` along a payment path at odds with
> the ordering of timelocks ?
>
I don't think it is. There is indeed a time lock delta in case htlcs need
to be settled on-chain. But in the happy offchain scenario, the added (wall
clock) delay of a hop is tiny. So yes, they get paid from downstream a few
seconds less in hold fees than what they need to pay upstream, but I think
this is insignificant compared to the total compensation that they are
getting (which is based on the grace period that is advertised). To be
clear, for the calculation of the hold fee, it is the wall clock time that
is used and not the block height.
> > But this would also mean that anyone can send out an htlc and collect
> hold fees unconditionally. Therefore routing nodes advertise on the network
> their `hold_grace_period`. When routing nodes accept an htl> to forward,
> they're willing to pay hold fees for it. But only if they added a delay
> greater than `hold_grace_period` for relaying the payment and its response.
> If they relayed in a timely fashion, they exp> ect the sender of the htlc
> to cover those costs themselves. If the sender is also a routing node, the
> sender should expect the node before them to cover it. Of course, routing
> nodes can't be trusted. So in> practice we can just as well assume that
> they'll always try to claim from the prior node the maximum amount in
> compensation.
>
> Assuming `hodl_fee_rate` are near-similar along the payment path, you have
> a concern when the HTLC settlement happens at period N on the outgoing link
> and at period N+1 on the incoming link due to clock differences. In this
> case, a routing node will pay a higher `hodl_fee_rate` than received.
>
> I think this is okay, that's an edge case, only leaking a few sats.
>
Is this the same concern as above or slightly different? Or do you mean
clock differences between the endpoints of a channel? For that, I'd think
that there needs to be some tolerance to smooth out disagreements. But yes,
in general as long as a node is getting a positive amount, it is probably
okay to tolerate a few rounding errors here and there.
> A more concerning one is when the HTLC settlement happens at period N on
> the outgoing link and your incoming counterparty goes offline. According to
> the HTLC relay contract, the `hodl_fee_rate` will be inflated until the
> counterparty goes back online and thus the routing node is at loss. And
> going offline is a really lawful behavior for mobile clients, even further
> if you consider mailbox-style of HTLC delivery (e.g Lightning Rod). You
> can't simply label such counterparty as malicious.
>
> And I don't think counterparties can trust themselves about their onliness
> to suspend the `hodl_fee_rate` inflation. Both sides have an interest to
> equivocate, the HTLC sender to gain a higher fee, the HTLC relayer to save
> the fee while having received one on the incoming link ?
>
Yes, that is a good point. But I do think that it is reasonable that a node
that can go offline doesn't charge a hodl fee. Those nodes aren't generally
forwarding htlcs anyway, so it would just be for their own outgoing
payments. Without charging a hodl fee for outgoing payments, they risk that
their channel peer delays the htlc for free. So they should choose their
peers carefully. It seems that at the moment mobile nodes are often
connected to a known LSP already, so this may not be a real problem. The
policies for a channel can be asymmetric with the mobile node not charging
hold fees for its outgoing htlcs to the LSP, while the LSP does charge hold
fees for htlcs that its forwards to the mobile node.
For the mailbox scenario, I think it is fair that someone is going to pay
for all those locked htlcs along the route. If the LSP decides to hold the
htlc until the destination comes online, they need to find a way to get the
mailbox bill paid.
All of this indeed also implies that nodes that do charge hold fees, need
to make sure to stay online. Otherwise peers may close channels with them
because they are unreliable and charging for their own outage.
> > Even though the proposal above is not fundamentally different from what
> was known already, I do think that it adds the flexibility that we need to
> not take a step back in terms of functionality (fair prici> ng for hodl
> invoices and its applications). Plus that it simplifies the parameter set.
>
> Minding the concerns raised above, I think this proposal is an improvement
> and would merit a specification draft, at least to ease further reasoning
> on its economic and security soundness. As a side-note, we're working
> further on Stake Certificates, which I believe is better for long-term
> network economics by not adding a new fee burden on payments. We should be
> careful to not economically outlaw micropayments.
>
Yes, we should be careful not to outlaw micropayments. But I don't think
the hold fees as described above do this. Because the fees are modeled as
close to the real costs as possible, it can only be fair? Tiny amounts that
settle quickly should need only very small hold fees. But if the tiny
amount gets stuck for a week and occupies an htlc slot in each of its 25
hops through multi-btc wumbo channels, yes, than it should be costly?
> If we think channel jamming is concerning enough in the short-term, we can
> deploy a bidirectional upfront payment-style of proposal now and consider a
> better solution when it's technically mature.
>
It remains unclear how much time we still have to fix this. Already today
there are nodes on the network that benefit from short interruptions of
large channel sets between the bigger nodes. During those interruptions,
they provide a fallback route at a premium price. It is not difficult to
come up with actions that happen to make those disruptions more likely to
happen. I wouldn't take too many chances with this.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210212/835761e2/attachment-0001.html>;