Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2021-02-14 📝 Original message: I've made a first attempt ...
📅 Original date posted:2021-02-14
📝 Original message:
I've made a first attempt at projecting this idea onto the existing spec:
https://github.com/lightningnetwork/lightning-rfc/pull/843. This may also
clarify some of the questions that haven't been answered yet.
Joost
On Fri, Feb 12, 2021 at 2:29 PM Antoine Riard <antoine.riard at gmail.com>
wrote:
> 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/20210214/c9e283f4/attachment.html>;
📝 Original message:
I've made a first attempt at projecting this idea onto the existing spec:
https://github.com/lightningnetwork/lightning-rfc/pull/843. This may also
clarify some of the questions that haven't been answered yet.
Joost
On Fri, Feb 12, 2021 at 2:29 PM Antoine Riard <antoine.riard at gmail.com>
wrote:
> 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/20210214/c9e283f4/attachment.html>;