> The risk of hitting the chain that you mention can be factored into this > base part as well. The hold fee rate would then be defined in the form (2 > sat + 1%) per minute.
I think this works if the base fee is paid at HTLC commitment lock-in. Otherwise, you're still exposed to the chain-hit risk, the channel might break at any time and the timevalues of the pending forward HTLC set will be lost. Note, it's likely the hedge to be probabilistic as you won't make HTLC receivers pay for the effective timevalue but only a fragment computed from the expected outgoing HTLC traffic during channel lifetime. A smart channel relay policy will discount chain-hit risks for stable links, incentivizing your counterparties to be good peers. > Is this the same concern as above or slightly different? Or do you mean > clock differences between the endpoints of a channel? For that, I'd think > that there needs to be some tolerance to smooth out disagreements. But yes, > in general as long as a node is getting a positive amount, it is probably > okay to tolerate a few rounding errors here and there. This is slightly different concern, HTLC settlement may happen at different wall clock time periods between downstream/upstream. Let's say a HTLC is relayed across Alice, Bob, Caroll. The HTLC is successfully settled at N between Bob and Caroll, with N the number of minutes since htlc lock-in. Caroll pays N * `hold_fee_rate` to Bob. As upstream settlement isn't atomic, it happens at N+1. Bob pays N * `hold_fee_rate` to Alice. Bob loss 1 * `hold_fee_rate`. For normal operations, I concede it should happen rarely enough for this being an edge-case. > Yes, that is a good point. But I do think that it is reasonable that a node > that can go offline doesn't charge a hodl fee. Those nodes aren't generally > forwarding htlcs anyway, so it would just be for their own outgoing > payments. Without charging a hodl fee for outgoing payments, they risk that > their channel peer delays the htlc for free. So they should choose their > peers carefully. It seems that at the moment mobile nodes are often > connected to a known LSP already, so this may not be a real problem. I think the reasoning holds for mobile clients not charging hold fees. Most of the time, your LSP doesn't have an interest to delay your HTLC, better to succeed/fail quickly to release the liquidity to potentially earn fees on another payment. The only case might be when all the outgoing liquidity of your LSPs are already near-busy and they have to select between your HTLC to forward and the one from another spoke. Minding this, hold fees charged by mobile clients might be a way to prioritize their payments. > All of this indeed also implies that nodes that do charge hold fees, need > to make sure to stay online. Otherwise peers may close channels with them > because they are unreliable and charging for their own outage. And this is the point where it becomes tricky. A malicious upstream node mimic offliness to inflate its due hold fee. Considering the long-term protocol trend to pour the unilateral closing fee burden on the counterparty deciding to go onchain, it won't be economical to do so if the extorted hold fees is inferior to channel closing onchain fees. So you might have this cat-and-mouse game play many times until it's obvious for a channel scoring logic that this peer is malicious and the channel must be closed. In-between the accumulated hold fees might have been superior to the cost of channel opening... I can really see a sophisticated attacker able to escape such channel blacklist heuristics. > Yes, we should be careful not to outlaw micropayments. But I don't think > the hold fees as described above do this. Because the fees are modeled as > close to the real costs as possible, it can only be fair? Tiny amounts that > settle quickly should need only very small hold fees. But if the tiny > amount gets stuck for a week and occupies an htlc slot in each of its 25 > hops through multi-btc wumbo channels, yes, than it should be costly? I agree that any packet which holds liquidity for a while should cover slot costs and timevalue, even if the value transferred is in fine inferior to the final hold fees. In that case, it should be up to the original sender to arbitrate between its expected traffic and the opportunity to open a channel to shorten its payment paths. Still, a "very small hold fees" might scope a lot of use-cases, which are hard to care about because they might not exist yet. Compared to leveraging a resource (channel UTXOs) which is already assumed to be owned by Lightning users. Le dim. 14 févr. 2021 à 13:05, Joost Jager <joost.ja...@gmail.com> a écrit : > 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
