<div dir="ltr"><div dir="ltr"><div>Hi Joost,<br><br>Thanks for working on this and keeping raising awareness about channel jamming.<br><br>> 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.<br><br>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.<br><br>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.<br><br>Is assuming increasing `hodl_fee_rate` along a payment path at odds with the ordering of timelocks ?<br><br>> 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.<br><br>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. <br><br>I think this is okay, that's an edge case, only leaking a few sats.<br><br>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.<br><br>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 ?<br><br>> 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.<br><br>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.<br><br><br></div>Antoine<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 11 févr. 2021 à 10:25, Joost Jager <<a href="mailto:joost.jager@gmail.com">joost.jager@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi ZmnSCPxj,</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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"?<br>
<br>
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.<br>
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.<br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Joost</div></div></div>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href="mailto:Lightning-dev@lists.linuxfoundation.org" target="_blank">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
</blockquote></div></div>