Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming)
> > This struck me as an extremely salient point. One thing that has been > noticeable missing from these discussions is any sort of threat model or > attacker > profile. Given this is primarily a griefing attack, and the attacker > doesn't > stand any direct gain, how high a fee is considered "adequate" deterrence > without also dramatically increasing the cost of node operation in the > average case? > I think that the first instances that we'll see of this attack will be executed by routing node operators that don't mind operating in a gray area. Apparently the popularity of the Lightning Network has risen to the point where it is possible for an operator to earn thousands of dollars per month in routing fees. Imagine how much this could be when you're actively jamming the competition's channels. Not only can you capture their traffic, but it will also be possible to command a higher fee rate because senders probably still want those payments to go through. Joost ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming)
> I think the problem of accidental channel closure is getting ignored by > devs. > > If we think any anti-DoS fee will be "insignificant" compared to the cost > of closing and reopening a channel, maybe dev attention should be on > fixing accidental channel closure costs than any anti-DoS fee mechanism. > > Any deterrence of the channel jamming problem is economic so if the > anti-DoS fee is tiny, then its deterrence will be tiny as well. This struck me as an extremely salient point. One thing that has been noticeable missing from these discussions is any sort of threat model or attacker profile. Given this is primarily a griefing attack, and the attacker doesn't stand any direct gain, how high a fee is considered "adequate" deterrence without also dramatically increasing the cost of node operation in the average case? If an attacker has say a budget of 20 BTC to blow as they just want to see the world burn, then most parametrizations of attempt fees are likely insufficient. In addition, if the HTLC attempt/hold fees rise well above routing fees, then costs are also increased for senders in addition to routing nodes. Also IMO, it's important to re-state, that if channels are parametrized properly (dust values, max/min HTLC, private channels, micropayment specific channels, etc), then there is an inherent existing cost re the opportunity cost of committing funds in channels and the chain fee cost of making the series of channels in the first place. Based on the discussion above, it appears that the decaying fee idea needs closer examination to ensure it doesn't increase the day to day operational cost of a routing node in order to defend against threats at the edges. Nodes go down all the time for various reasons: need to allocate more disk, software upgrade, infrastructure migrations, power outages, etc, etc. By adding a steady decay cost, we introduce an idle penalty for lack of uptime when holding an HTLC, similar to the availability slashing in PoS systems. It would be unfortunate if an end result of such a solution is increasing node operation costs as a whole, (which has other trickle down effects: less nodes, higher routing fees, strain of dev-ops teams to ensure higher uptime or loss of funds, etc), while having negligible effects on the "success" profile of such an attack in practice. If nodes wish to be compensated for committing capital to Lightning itself, then markets such as Lightning Pool which rewards them for allocating the capital (independent of use) for a period of time can help them scratch that itch. Returning back to the original point, it may very well be the case that the very first solution proposed (circa 2015) to this issue: close out the channel and send back a proof of closure, may in fact be more desirable from the PoV of enforcing tangible costs given it requires the attacker to forfeit on-chain fees in the case of an unsuccessful attack. Services that require long lived HTLCs (HTLC mailboxes, etc) can flag the HTLCs as such in the onion payload allowing nodes to preferentially forward or reject them. Zooming out, I have a new idea in this domain that attempts to tackle things from a different angle. Assuming that any efforts to add further off-chain costs are insignificant in the face of an attacker with few constraints w.r.t budget, perhaps some efforts should be focused on instead ensuring that if there's "turbulence" in the network, it can gracefully degraded to a slightly more restricted operating mode until the storm passes. If an attacker spends coins/time/utxos, etc to be in position to distrust things, but then finds that things are working as normal, such a solution may serve as a low cost deterrence mechanism that won't tangibly increase operation/forwarding/payment costs within the network. Working out some of the kinks re the idea, but I hope to publish it sometime over the next few days. -- Laolu On Fri, Feb 12, 2021 at 8:24 PM ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Good morning Joost, > > > > 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
Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming)
To further illustrate the interactions of the hold fee rate proposal, I've
created a spreadsheet that calculates the fees for a three hop route:
https://docs.google.com/spreadsheets/d/1UX3nMl-L9URO3Vd49DBVaubs6fdi6wxSb-ziSVlF6eo/edit?usp=sharing
(if there was a way to paste a working spreadheet into an email, I would
have done it...)
You can make a copy and try out various different values. The actual hold
time is particularly interesting, because it allows you to see how much
holding an htlc is going to cost you.
Example 1:
If all nodes want a 5% yearly return on their held capital and one sends a
1 million sat payment across three hops that is held for one hour by the
recipient, the recipient will be charged about 20 sats for this.
Example 2:
With the same configuration, a 1 sat micropayment that is settled
near-instantly will cost the sender around 130 msat in hold fees.
Joost
On Thu, Feb 11, 2021 at 3:28 PM Joost Jager wrote:
> Hi all,
>
> Things have been quiet around channel jamming lately, but the
> vulnerability it still there as much as it was before. I've participated in
> an (isolated) mainnet channel jamming experiment (
> https://bitcoinmagazine.com/articles/good-griefing-a-lingering-vulnerability-on-lightning-network-that-still-needs-fixing)
> which only confirmed the seriousness of the issue.
>
> BIDIRECTIONAL UPFRONT PAYMENT
>
> Of all the proposals that have been presented, t-bast's remix of forward
> and backward upfront payments (
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002862.html
> ,
> https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md#bidirectional-upfront-payment)
> indicates in my opinion the most promising direction.
>
> One characteristic of the proposal is that the `hold_fees` are
> time-independent. If an htlc doesn't resolve within the `grace_period`, the
> receiver of the htlc will be forced to pay the full hold fee. The hold fee
> should cover the expenses for locking up an htlc for the maximum duration
> (could be 2000 blocks), so this can be a significant penalty. Applications
> such as atomic onchain/offchain swaps (Lightning Loop and others) rely on
> locking funds for some time and could get expensive with a fixed hold fee.
>
> HOLD FEE RATE
>
> 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 to relate
> the fees paid more directly to the actual costs incurred and thereby reduce
> the number of parameters.
>
> In a Lightning channel, the sender of an htlc always incurs the cost. The
> htlc value is deduced from their balance and the money can't be used for
> other purposes when the htlc is in flight. Therefore ideally a routing node
> is compensated for the time that their outgoing htlc is in flight.
>
> To communicate this cost to the outside world, routing nodes advertise a
> `hold_fee_rate` as part of their channel forwarding policy. An example
> would be "0.3 msat per sat per minute". So if someone wants to forward 10k
> sat through that channel and the htlc remains in flight for 5 minutes, the
> routing node would like to see a compensation of 0.3msat * 10k sat * 5 mins
> = 15 sat. (it is possible to extend the model with a base fee rate to also
> cover the cost of an occupied slot on the commitment tx)
>
> The question here again is who is going to pay the hold fee. The answer is
> that it is primarily the receiver of the htlc who is going to pay. They are
> the ones that can fail or settle the htlc and are therefore in control of
> the hold time ("Reverse upfront payment")
>
> 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 htlc 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 expect 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.
>
> This is the basic idea. Routing nodes have real costs for the lock up of
> their money and will be compensated for it.
>
> To coordinate the payment of the fees, the `update_add_htlc` message is
> extended with:
> * `hold_fee_rate`: the fee rate that the sender charges for having the
> htlc in-flight (msat per sat per min)
> * `hold_fee_discount`: the absolute fee discount (sat) that the receiver
> gets as a compensation for hold fees that couldn't be claimed downstream
> because of the grace periods (the worst case
Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming)
> 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 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 > wrote: > >> Hi Joost, >> >>
Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming)
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 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 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
Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming)
Good morning Joost, > > 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. I think the problem of accidental channel closure is getting ignored by devs. If we think any anti-DoS fee will be "insignificant" compared to the cost of closing and reopening a channel, maybe dev attention should be on fixing accidental channel closure costs than any anti-DoS fee mechanism. Any deterrence of the channel jamming problem is economic so if the anti-DoS fee is tiny, then its deterrence will be tiny as well. It seems to me that adding this anti-DoS fee *on top of* an accidental channel closure is just adding insult to injury, when we should probably be considering how to ameliorate the injury. Otherwise forwarding nodes will themselves be deterred from operating at all. > > Is assuming increasing `hodl_fee_rate` along a payment path at odds with > > the ordering of timelocks ? > > I don't think it is. In terms of privacy, this is more dangerous. The decrementing timelock already leaks an upper bound on the distance to payee. An incrementing holdfee leaks an upper bound on the distance to payer. This translates to a single payment-part being more easily associated with the payer and payee. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming)
Hi Antoine, 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. > Yes, that could be another reason to define `hodl_fee_rate` as a base fee rate plus a component that is proportional to the amount. As mentioned in my initial email, the base fee can be used to cover the cost of occupying an htlc slot (which can be a significant factor for a large wumbo channel). 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. > 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 ? > I don't think it is. There is indeed a time lock delta in case htlcs need to be settled on-chain. But in the happy offchain scenario, the added (wall clock) delay of a hop is tiny. So yes, they get paid from downstream a few seconds less in hold fees than what they need to pay upstream, but I think this is insignificant compared to the total compensation that they are getting (which is based on the grace period that is advertised). To be clear, for the calculation of the hold fee, it is the wall clock time that is used and not the block height. > > 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. > 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. > 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 ? > 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. The policies for a channel can be asymmetric with the mobile node not charging hold fees for its outgoing htlcs to the LSP, while the LSP does charge hold fees for htlcs that its forwards to the mobile node. For the mailbox scenario, I think it is fair that someone is going to pay for all those locked htlcs along the route. If the LSP decides to hold the htlc until the destination comes online, they need to find a way to get the mailbox bill paid. All of this indeed also implies that nodes that do charge hold fees, need to make sure to stay
Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming)
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
Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming)
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
Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming)
Good morning Joost,
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.
Regards,
ZmnSCPxj
> Hi all,
>
> Things have been quiet around channel jamming lately, but the vulnerability
> it still there as much as it was before. I've participated in an (isolated)
> mainnet channel jamming experiment
> (https://bitcoinmagazine.com/articles/good-griefing-a-lingering-vulnerability-on-lightning-network-that-still-needs-fixing)
> which only confirmed the seriousness of the issue.
>
> BIDIRECTIONAL UPFRONT PAYMENT
>
> Of all the proposals that have been presented, t-bast's remix of forward and
> backward upfront payments
> (https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002862.html,
>
> https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md#bidirectional-upfront-payment)
> indicates in my opinion the most promising direction.
>
> One characteristic of the proposal is that the `hold_fees` are
> time-independent. If an htlc doesn't resolve within the `grace_period`, the
> receiver of the htlc will be forced to pay the full hold fee. The hold fee
> should cover the expenses for locking up an htlc for the maximum duration
> (could be 2000 blocks), so this can be a significant penalty. Applications
> such as atomic onchain/offchain swaps (Lightning Loop and others) rely on
> locking funds for some time and could get expensive with a fixed hold fee.
>
> HOLD FEE RATE
>
> 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 to relate
> the fees paid more directly to the actual costs incurred and thereby reduce
> the number of parameters.
>
> In a Lightning channel, the sender of an htlc always incurs the cost. The
> htlc value is deduced from their balance and the money can't be used for
> other purposes when the htlc is in flight. Therefore ideally a routing node
> is compensated for the time that their outgoing htlc is in flight.
>
> To communicate this cost to the outside world, routing nodes advertise a
> `hold_fee_rate` as part of their channel forwarding policy. An example would
> be "0.3 msat per sat per minute". So if someone wants to forward 10k sat
> through that channel and the htlc remains in flight for 5 minutes, the
> routing node would like to see a compensation of 0.3msat * 10k sat * 5 mins =
> 15 sat. (it is possible to extend the model with a base fee rate to also
> cover the cost of an occupied slot on the commitment tx)
>
> The question here again is who is going to pay the hold fee. The answer is
> that it is primarily the receiver of the htlc who is going to pay. They are
> the ones that can fail or settle the htlc and are therefore in control of the
> hold time ("Reverse upfront payment")
>
> 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 htlc 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 expect 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.
>
> This is the basic idea. Routing nodes have real costs for the lock up of
> their money and will be compensated for it.
>
> To coordinate the payment of the fees, the `update_add_htlc` message is
> extended with:
> * `hold_fee_rate`: the fee rate that the sender charges for having the htlc
> in-flight (msat per sat per min)
> * `hold_fee_discount`: the absolute fee discount (sat) that the receiver gets
> as a compensation for hold fees that couldn't be claimed downstream because
> of the grace periods (the worst case amount).
> (the previous `hold_grace_period` in `update_add_htlc` is no longer needed)
>
> When an htlc is resolved, the receiver of
[Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming)
Hi all,
Things have been quiet around channel jamming lately, but the vulnerability
it still there as much as it was before. I've participated in an (isolated)
mainnet channel jamming experiment (
https://bitcoinmagazine.com/articles/good-griefing-a-lingering-vulnerability-on-lightning-network-that-still-needs-fixing)
which only confirmed the seriousness of the issue.
BIDIRECTIONAL UPFRONT PAYMENT
Of all the proposals that have been presented, t-bast's remix of forward
and backward upfront payments (
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002862.html
,
https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md#bidirectional-upfront-payment)
indicates in my opinion the most promising direction.
One characteristic of the proposal is that the `hold_fees` are
time-independent. If an htlc doesn't resolve within the `grace_period`, the
receiver of the htlc will be forced to pay the full hold fee. The hold fee
should cover the expenses for locking up an htlc for the maximum duration
(could be 2000 blocks), so this can be a significant penalty. Applications
such as atomic onchain/offchain swaps (Lightning Loop and others) rely on
locking funds for some time and could get expensive with a fixed hold fee.
HOLD FEE RATE
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 to relate
the fees paid more directly to the actual costs incurred and thereby reduce
the number of parameters.
In a Lightning channel, the sender of an htlc always incurs the cost. The
htlc value is deduced from their balance and the money can't be used for
other purposes when the htlc is in flight. Therefore ideally a routing node
is compensated for the time that their outgoing htlc is in flight.
To communicate this cost to the outside world, routing nodes advertise a
`hold_fee_rate` as part of their channel forwarding policy. An example
would be "0.3 msat per sat per minute". So if someone wants to forward 10k
sat through that channel and the htlc remains in flight for 5 minutes, the
routing node would like to see a compensation of 0.3msat * 10k sat * 5 mins
= 15 sat. (it is possible to extend the model with a base fee rate to also
cover the cost of an occupied slot on the commitment tx)
The question here again is who is going to pay the hold fee. The answer is
that it is primarily the receiver of the htlc who is going to pay. They are
the ones that can fail or settle the htlc and are therefore in control of
the hold time ("Reverse upfront payment")
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 htlc 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 expect 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.
This is the basic idea. Routing nodes have real costs for the lock up of
their money and will be compensated for it.
To coordinate the payment of the fees, the `update_add_htlc` message is
extended with:
* `hold_fee_rate`: the fee rate that the sender charges for having the htlc
in-flight (msat per sat per min)
* `hold_fee_discount`: the absolute fee discount (sat) that the receiver
gets as a compensation for hold fees that couldn't be claimed downstream
because of the grace periods (the worst case amount).
(the previous `hold_grace_period` in `update_add_htlc` is no longer needed)
When an htlc is resolved, the receiver of the htlc will pay the sender the
`hold_fee_rate` minus `hold_fee_discount` (exact details of how to
integrate this into the channel state machine and deal with clock shift
tbd).
It is up to the sender of a payment to construct the onion payloads such
that all nodes along the route will have their costs covered.
EXAMPLE
A > B > C > D
Every node charges 0.6 msat/sat/minute with a hold grace period of 1
minute. In this example, the routing fees are zero.
A wants to send 1000 sat to D.
A will charge B a hold fee rate of 0.6 sat/min (1000 sat at 0.6
msat/sat/min). B will charge C a hold fee rate of 1.2 sat/min to cover both
its own cost and what must be paid back to A. C will charge D a hold fee
rate of 1.8 sat/min to cover the costs of A, B and C.
D has a grace period of 1 minute. At the 1.8 sat/min fee rate that C
charges, D would need to pay a maximum of 1.8 sat if it meets its grace
deadline just in time. C pays the 1.8 sats to D as
