Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2021-02-12 📝 Original message: Hi Joost, Thanks for ...
📅 Original date posted:2021-02-12
📝 Original message:
Hi Joost,
Thanks for working on this and keeping raising awareness about channel
jamming.
> In this post I'd like to present a variation of bidirectional upfront
payments that uses a time-proportional hold fee rate to address the
limitation above. I also tried to come up with a system that aims > relate
the fees paid more directly to the actual costs incurred and thereby reduce
the number of parameters.
Not considering hold invoices and other long-term held packets was one of
my main concerns in the previous bidirectional upfront payments. This new
"hodl_fee_rate" is better by binding the hold fee to the effectively
consumed timelocked period of the liquidity and not its potential maximum.
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. 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 ?
> 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.
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 ?
> 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. 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.
Antoine
Le jeu. 11 févr. 2021 à 10:25, Joost Jager <joost.jager at gmail.com> a écrit :
> Hi ZmnSCPxj,
>
> Not quite up-to-speed back into this, but, I believe an issue with using
>> feerates rather than fixed fees is "what happens if a channel is forced
>> onchain"?
>>
>> Suppose after C offers the HTLC to D, the C-D channel, for any reason, is
>> forced onchain, and the blockchain is bloated and the transaction remains
>> floating in mempools until very close to the timeout of C-D.
>> C is now liable for a large time the payment is held, and because the C-D
>> channel was dropped onchain, presumably any parameters of the HTLC
>> (including penalties D owes to C) have gotten fixed at the time the channel
>> was dropped onchain.
>>
>
> The simplicity of the fixed fee is that it bounds the amount of risk that
>> C has in case its outgoing channel is dropped onchain.
>>
>
> The risk is bound in both cases. If you want you can cap the variable fee
> at a level that isn't considered risky, but it will then not fully cover
> the actual cost of the locked-up htlc. Also any anti-DoS fee could very
> well turn out to be insignificant to the cost of closing and reopening a
> channel with the state of the mempool these days.
>
> Joost
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210212/846ce794/attachment.html>;
📝 Original message:
Hi Joost,
Thanks for working on this and keeping raising awareness about channel
jamming.
> In this post I'd like to present a variation of bidirectional upfront
payments that uses a time-proportional hold fee rate to address the
limitation above. I also tried to come up with a system that aims > relate
the fees paid more directly to the actual costs incurred and thereby reduce
the number of parameters.
Not considering hold invoices and other long-term held packets was one of
my main concerns in the previous bidirectional upfront payments. This new
"hodl_fee_rate" is better by binding the hold fee to the effectively
consumed timelocked period of the liquidity and not its potential maximum.
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. 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 ?
> 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.
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 ?
> 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. 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.
Antoine
Le jeu. 11 févr. 2021 à 10:25, Joost Jager <joost.jager at gmail.com> a écrit :
> Hi ZmnSCPxj,
>
> Not quite up-to-speed back into this, but, I believe an issue with using
>> feerates rather than fixed fees is "what happens if a channel is forced
>> onchain"?
>>
>> Suppose after C offers the HTLC to D, the C-D channel, for any reason, is
>> forced onchain, and the blockchain is bloated and the transaction remains
>> floating in mempools until very close to the timeout of C-D.
>> C is now liable for a large time the payment is held, and because the C-D
>> channel was dropped onchain, presumably any parameters of the HTLC
>> (including penalties D owes to C) have gotten fixed at the time the channel
>> was dropped onchain.
>>
>
> The simplicity of the fixed fee is that it bounds the amount of risk that
>> C has in case its outgoing channel is dropped onchain.
>>
>
> The risk is bound in both cases. If you want you can cap the variable fee
> at a level that isn't considered risky, but it will then not fully cover
> the actual cost of the locked-up htlc. Also any anti-DoS fee could very
> well turn out to be insignificant to the cost of closing and reopening a
> channel with the state of the mempool these days.
>
> Joost
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210212/846ce794/attachment.html>;