From antoine.riard at gmail.com Fri Feb 12 13:29:11 2021 From: antoine.riard at gmail.com (Antoine Riard) Date: Fri, 12 Feb 2021 08:29:11 -0500 Subject: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming) In-Reply-To: References: Message-ID: 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 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: