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.ri...@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.ja...@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@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
