Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation
Hi, > The only damage we can observe in the protocol is routing fees. If we go ahead with our suggestion, it will be straightforward to choose a different threshold based on the preference of a node. We have some suggestions for receiving nodes, for example. I think there is another obvious damage that we can observe at the protocol-level, on-chain fees if the target node opens more channel to compensate the slow-jammed ones, or if there is an automatic force-close in reason of the low-yield of a channel by the liquidity allocation engine (e.g something like CLBOSS). Of course, the "reaction" of a target node is first not very standardized by a BOLT, second very specific in function of the node activity (pure routing node, LSP, merchant). So it sounds better deferred to the ulterior level of development of the mitigations, let's hope we can solve the simple cases first. > The difficulty to gain reputation is proportional to the amount of damage that can be inflicted. Okay, I think this is where I diverge on the soundness of the HTLC endorsement solution. For the historical note, when stakes certificates as a jamming mitigation where proposed back in 2020 [0], the intuition on the soundness of the security model was it would cost as much for an adversary to acquire a "fresh" UTXO proof-of-ownership than the level of damage they can inflict. Which sounds to me the same intuition you're sharing here. After doing more research the past year [1], it was realized on my side than the cost function of the adversary is hard to formalize in a world where the adversary capabilities (quid if the adversary is a miner ?), source of information (quid if the adversary has better on-chain fees estimation ?), attacking strategy (quid if they batch a jamming against multiple target nodes from a _single_ UTXO?) are all unknowns or "hard-to-guess" variables. Additionally, the target node source of information is unknown, or at the very best for the purpose of mitigation design, we can do the assumptions based on standard/implementation default. However here an adversary is always free to have a better source of information (the historical Shannon's quote "The enemy knows the system" in matters of cryptanalysis). So my own intellectual conclusion is that ideally a reputation-based mitigation strategy should have a homomorphism with a monetary-based mitigation strategy in the eventuality of a jamming adversary gaining an informational asymmetry. A monetary-based mitigation strategy has the formal advantage that it can be quantified 100% to the worst-damage inflicted from the preference of the target node itself. > "A significant cost", unlike right now where it's practically free. Because we don't know how deep are the pockets of the attacker, our focus is on compensating the victim. Yes, I think "compensating the victim" is a good direction from the insight laid out just above. Though note the theoretical caveat on the (probable) necessity of measuring reputation in pure monetary terms. > Because a lot of the criteria are "soft" (UX, ease of implementation), we cannot prove theorems. We are working on further simulations for the quantifiable criteria, to see if theory meets practice. > Note that DDoS attacks are notoriously difficult to mitigate (see [0], for example), so we are trying to do our best in the context of lightning using the available tools This is why the modern security models and cryptanalysis are based on assumptions (e.g the DL problem or hardware enforcement of your OS boot). Such assumptions laying out of mitigations soundness analysis "soft" criterias. Note such intellectual process has been followed as a standard design in the redaction of modern Bitcoin standards like BIP340 (schnorr) and BIP341 (taproot). For the mathematical note, theorems are not "fully" proved (see the failure of Hilbert's program to found XXth century mathematics on a complete set of axioms), though the proving process has a valuable interest to select theorems for practical applications. > We are working on further simulations for the quantifiable criteria, to see if theory meets practice. > Note that DDoS attacks are notoriously difficult to mitigate (see [0], for example), so we are trying to do our best in the context of lightning using the available tools. Note, modern DDoS attacks mitigations have been discussed using "tokens" blockchain as a basis for a monetary strategy (e.g the Tor project blog [0]). I think all past literature on DDoS attacks has to be reviewed under the light of a global "ledger" like the Bitcoin blockchain where all the DDoS attacks can be measured in terms of satoshis, a utility cost function shared de facto by all the participants of the system. > Simulation running as we speak. Formalization of the game-theory of jamming attacks advancing as we speak. Best, Antoine [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002884.html [1]
Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation
Hi, > Sure, I understand that in case of an attack, a routing node should have > been paid a significant fee sum by the peer originating the jamming > traffic. However from my understanding this is unclear with the proposed > htlc endorsement system than the fees paid are fully economically > compensating the damage inflicted to the victim ? > The only damage we can observe in the protocol is routing fees. If we go ahead with our suggestion, it will straightforward to choose a different threshold based on the preference of a node. We have some suggestions for receiving nodes, for example. > Or if it's a proportional compensation, and if proportional the ratio > between the fees and the reputation is static or dynamic, and if dynamic > which are the criterias of evaluation ? > The difficulty to gain reputation is proportional to the amount of damage that can be inflicted. > > Note, outlawing the cost of the attack from the system guarantees sounds > contrary to the htlc endorsement design goal shown in your gist: "the goal > of this proposal is to produce a mitigation that has...a significant cost > to persistent attackers", or are the design goals proposed elsewhere ? > "A significant cost", unlike right now where it's practically free. Because we don't know how deep are the pockets of the attacker, our focus is on compensating the victim. > So I still don't know the precise problem to be solved by any jamming > mitigation, in a formal fashion, nor the correctness conditions required of > a solution. As far as I can tell, such information is not present in the > "unjamming lightning" paper (while the paper claims to "systematically > analyze the solution space" it does not formalize the problem, at least in > terms of abstract definition that holds independently of the solution > adopted). > I think there is still an undervaluation of how much the liquidity griefing > issues affecting Lightning and second-layers, of which jamming is only one, > is novel from the viewpoint of financial cryptography/computer security > literature. At the best, I think we should aim to evaluate the > effectiveness of any jamming solution with the same conceptual rigor as > modern cryptanalysis (understood notions like shannon cipher, perfect > security, switching lemma). > Without such rigor of analysis, I don't think we'll be able to give > "measurable" bounds to any solution, and know when there is a wreckage > because we're modifying some subtle parameters like channel opening > default, or the adversaries can access superior sources of information to > decide when to launch a jamming attack where the sum paid does _not_ cover > the operational cost of a routing hop. > Because a lot of the criteria are "soft" (UX, ease of implementation), we cannot prove theorems. We are working on further simulations for the quantifiable criteria, to see if theory meets practice. Note that DDoS attacks are notoriously difficult to mitigate (see [0], for example), so we are trying to do our best in the context of lightning using the available tools. > So if you recognize that htlc endorsement can fluctuate the link-level > liquidity more than it does now, at the very least it would be good to come > with simulations on how it might downgrade HTLC routing traffic ? > Simulation running as we speak. Best, Clara [0] https://www.sciencedirect.com/science/article/abs/pii/S1389128603004250?casa_token=BauKTUZ1yEYA:Ny9OvPXunkvLZgJD1bYQ_amV-rsMVRbYKozWchYB9ZpFZ3dNFfJnK74UYl7di9R24aDhrw ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation
Hi, > Bob can also forward but not endorse Alice's HTLC. All of this is a function of how much credit Bob gives to Alice's judgment. In case of jamming, the damage that Alice inflicts should be proportional to the revenue she recently created for Bob, and so the more damage, the higher the threshold. > This system guarantees that if a node was jammed, it was paid a significant some prior to the attack happening. There is no claim about who is paying or the cost of the attack. Sure, I understand that in case of an attack, a routing node should have been paid a significant fee sum by the peer originating the jamming traffic. However from my understanding this is unclear with the proposed htlc endorsement system than the fees paid are fully economically compensating the damage inflicted to the victim ? Or if it's a proportional compensation, and if proportional the ratio between the fees and the reputation is static or dynamic, and if dynamic which are the criterias of evaluation ? Note, outlawing the cost of the attack from the system guarantees sounds contrary to the htlc endorsement design goal shown in your gist: "the goal of this proposal is to produce a mitigation that has...a significant cost to persistent attackers", or are the design goals proposed elsewhere ? So I still don't know the precise problem to be solved by any jamming mitigation, in a formal fashion, nor the correctness conditions required of a solution. As far as I can tell, such information is not present in the "unjamming lightning" paper (while the paper claims to "systematically analyze the solution space" it does not formalize the problem, at least in terms of abstract definition that holds independently of the solution adopted). I think there is still an undervaluation of how much the liquidity griefing issues affecting Lightning and second-layers, of which jamming is only one, is novel from the viewpoint of financial cryptography/computer security literature. At the best, I think we should aim to evaluate the effectiveness of any jamming solution with the same conceptual rigor as modern cryptanalysis (understood notions like shannon cipher, perfect security, switching lemma). Without such rigor of analysis, I don't think we'll be able to give "measurable" bounds to any solution, and know when there is a wreckage because we're modifying some subtle parameters like channel opening default, or the adversaries can access superior sources of information to decide when to launch a jamming attack where the sum paid does _not_ cover the operational cost of a routing hop. I'm not pretending to have done the "cryptoeconomics-analysis" work for the solution I'm proposing (staking credentials) or something like circuit breaker. I just would like to underscore we should be quite cautious in deploying half-baked mitigations, that might provoke more harm than relief to routing node operators. Sorry not sorry if it's interpreted as a rant, we have already enough broken stuff in Lightning... > The reading on the channel liquidity can change for different users using different routes, but the information a node gets is what liquidity is available for them (and not the state of the channel in general). > This indeed can fluctuate more than it does now, but so is the liquidity available for a specific node. So if you recognize that htlc endorsement can fluctuate the link-level liquidity more than it does now, at the very least it would be good to come with simulations on how it might downgrade HTLC routing traffic ? Again on this last point, I would say intuitively any other proposed jamming solution would come with downsides on the routing traffic succes, though hard to say the trade-offs. Best, Antoine Le mer. 31 mai 2023 à 21:21, Clara Shikhelman a écrit : > Hi, > >> I think the distinction you're proposing between routing fees and reputation >> revenue matters in the HTLC endorsement model. For the example I'm using >> let's say Caroll and Bob share the same exact parameters, >> *reputation_revenue* = 1,000, *routing_window*=100 and *routing_window*=10, >> where the reputation revenue of Bob towards Caroll is made from multiple >> incoming links. >> >> For each HTLC forwarding request issued from Alice, Bob has to make the >> decision between refusing Alice HTLC forward over the Caroll incoming link, >> and lose an opportunity of fee income, or accept the HTLC and suffers from a >> damage if Alice reveals a posteriori as a jamming attacker. >> >> Bob can also forward but not endorse Alice's HTLC. All of this is a > function of how much credit Bob gives to Alice's judgment. In case of > jamming, the damage that Alice inflicts should be proportional to the > revenue she recently created for Bob, and so the more damage, the higher > the threshold. > >> >> This is unclear to me how the compensation mechanism works in the chain of >> nodes that have high reputation with each other, and I still think the HTLC >> endorsement
Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation
Hi, > I think the distinction you're proposing between routing fees and reputation > revenue matters in the HTLC endorsement model. For the example I'm using > let's say Caroll and Bob share the same exact parameters, > *reputation_revenue* = 1,000, *routing_window*=100 and *routing_window*=10, > where the reputation revenue of Bob towards Caroll is made from multiple > incoming links. > > For each HTLC forwarding request issued from Alice, Bob has to make the > decision between refusing Alice HTLC forward over the Caroll incoming link, > and lose an opportunity of fee income, or accept the HTLC and suffers from a > damage if Alice reveals a posteriori as a jamming attacker. > > Bob can also forward but not endorse Alice's HTLC. All of this is a function of how much credit Bob gives to Alice's judgment. In case of jamming, the damage that Alice inflicts should be proportional to the revenue she recently created for Bob, and so the more damage, the higher the threshold. > > This is unclear to me how the compensation mechanism works in the chain of > nodes that have high reputation with each other, and I still think the HTLC > endorsement mitigation suffers from the classic issues of reputation systems > (i.e whitewashing). > > This system guarantees that if a node was jammed, it was paid a significant some prior to the attack happening. There is no claim about who is paying or the cost of the attack. I think there is a coupling effec introduced between the historical liquidity buckets of routing scoring algorithms and the introduction of endorsment scheme with adjustement of the channel liquidity and slots in function of local topology reputation. > > > See the LDK scoring engine comments here : > https://github.com/lightningdevkit/rust-lightning/blob/eec5ec6b50720144fc23503c3ee9c1c8850517ac/lightning/src/routing/scoring.rs#L336 > > The reading on the channel liquidity can change for different users using different routes, but the information a node gets is what liquidity is available for them (and not the state of the channel in general). This indeed can fluctuate more than it does now, but so is the liquidity available for a specific node. Best, Clara ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation
> I think it's important to differentiate between fees a node charges and > *reputation_revenue*. Reputation is determined as a function of the latter. > If Caroll has a very high *reputation_revenue* and Bob has a very low one, > then Bob probably won't have a high reputation with Caroll, as the amount > of fees he forwards to Caroll is smaller than the damage he can create. > That is, if Caroll is a huge node and Bob is a raspberry pi, then Bob will > never have a good reputation with Caroll. If they have similar > *reputation_revenue*, then getting a good reputation with Bob is as > difficult as getting a good reputation with Caroll. > > In your example (if I got it correctly) Bob's *reputation_revenue* = 1,000, > *reputation_window*=100 and *routing_window*=10. Could you explain what are > Caroll's parameters are in your example? The *fee_base_msat* does not > indicate Carolls *reputation_revenue* (unless Alice is the only one > transacting on the Bob-Caroll channel, and then she is the one paying for > Bob's reputation). > > That being said, we use *reputation_revenue *to estimate the damage an > attacker can create. If there is a chain of nodes that have high reputation > with each other, and they are jammed, they would be compensated for the > revenue lost during the attack. If Bob finds that having a high reputation > with Caroll is crucial and 1,000 sats will not compensate him for loosing > it, then he should either never endorse anything on that channel, or at > least put a higher bar than *reputation_revenue*. I think the distinction you're proposing between routing fees and reputation revenue matters in the HTLC endorsement model. For the example I'm using let's say Caroll and Bob share the same exact parameters, *reputation_revenue* = 1,000, *routing_window*=100 and *routing_window*=10, where the reputation revenue of Bob towards Caroll is made from multiple incoming links. For each HTLC forwarding request issued from Alice, Bob has to make the decision between refusing Alice HTLC forward over the Caroll incoming link, and lose an opportunity of fee income, or accept the HTLC and suffers from a damage if Alice reveals a posteriori as a jamming attacker. This is unclear to me how the compensation mechanism works in the chain of nodes that have high reputation with each other, and I still think the HTLC endorsement mitigation suffers from the classic issues of reputation systems (i.e whitewashing). > Not sure what you mean by that. I think there is a coupling effec introduced between the historical liquidity buckets of routing scoring algorithms and the introduction of endorsment scheme with adjustement of the channel liquidity and slots in function of local topology reputation. See the LDK scoring engine comments here : https://github.com/lightningdevkit/rust-lightning/blob/eec5ec6b50720144fc23503c3ee9c1c8850517ac/lightning/src/routing/scoring.rs#L336 Best, Antoine Le mer. 17 mai 2023 à 21:49, Clara Shikhelman a écrit : > Hi, > > >> The lack of transitivity of the reputation acquisition cost (e.g based on >> historical fees earned from forwards originating from the peer) between the >> hops of the payment path still raises a vulnerability issue for the >> endorsement scheme, I think. >> >> Namely, let's say you have Alice, Bob and Caroll where endorsement has >> been obtained by Alice on the Bob incoming link by paying fees for an >> amount of 1000 sats for the last 100 blocks. Caroll offers a far higher >> pricing on her incoming link from Bob, 1 sats as `fee_base_msat` on her >> endorsed slots. It sounds to me there is nothing preventing Alice from >> sacrificing her earned reputation to inflict a loss of routing fees damage >> on Caroll incoming link ? >> > > I think it's important to differentiate between fees a node charges and > *reputation_revenue*. Reputation is determined as a function of the > latter. If Caroll has a very high *reputation_revenue* and Bob has a very > low one, then Bob probably won't have a high reputation with Caroll, as the > amount of fees he forwards to Caroll is smaller than the damage he can > create. That is, if Caroll is a huge node and Bob is a raspberry pi, then > Bob will never have a good reputation with Caroll. If they have similar > *reputation_revenue*, then getting a good reputation with Bob is as > difficult as getting a good reputation with Caroll. > > In your example (if I got it correctly) Bob's *reputation_revenue* = > 1,000, *reputation_window*=100 and *routing_window*=10. Could you explain > what are Caroll's parameters are in your example? The *fee_base_msat* > does not indicate Carolls *reputation_revenue* (unless Alice is the only > one transacting on the Bob-Caroll channel, and then she is the one paying > for Bob's reputation). > > That being said, we use *reputation_revenue *to estimate the damage an > attacker can create. If there is a chain of nodes that have high reputation > with each other, and they are jammed, they
Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation
> > I'd be very interested in how many repeat interactions nodes get from > individual senders, since that also tells us how much use we can get > out of local-only reputation based systems, and I wouldn't be > surprised if, for large routing nodes, we have sufficient data for > them to make an informed decision, while the edges may be more > vulnerable, but they'd also be used by way fewer senders, and the > impact of an attack would also be proportionally smaller. > > I’m unclear on what you mean by “individual senders” here? In our > scheme, nodes only track local reputation for their direct peers so > what matters is their history with all HTLCs a peer has forwarded to > them (not whether they come from repeat senders). Apologies, upon rethinking this I realized I had been mixing two different proposals in my mind. The criticism of sender-based reputation does not apply if all we do is track our immediate neighbors. Sorry for the confusion. > It’s true that nodes that forward fewer HTLCs are less likely to be > able to build a good reputation with very active routing nodes. In the > regular operation of the network, this should have low to no impact on > their activity - they don’t require much from their peers anyway. > During an attack, small and low activity nodes will temporarily be in > competition for large routing nodes’ scarce liquidity and slots, but > will still be able to interact with similar nodes where they have > better chances of building a good reputation. That matches my own interpretation very well, thanks. Cheers, Christian ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation
Hi, > The lack of transitivity of the reputation acquisition cost (e.g based on > historical fees earned from forwards originating from the peer) between the > hops of the payment path still raises a vulnerability issue for the > endorsement scheme, I think. > > Namely, let's say you have Alice, Bob and Caroll where endorsement has > been obtained by Alice on the Bob incoming link by paying fees for an > amount of 1000 sats for the last 100 blocks. Caroll offers a far higher > pricing on her incoming link from Bob, 1 sats as `fee_base_msat` on her > endorsed slots. It sounds to me there is nothing preventing Alice from > sacrificing her earned reputation to inflict a loss of routing fees damage > on Caroll incoming link ? > I think it's important to differentiate between fees a node charges and *reputation_revenue*. Reputation is determined as a function of the latter. If Caroll has a very high *reputation_revenue* and Bob has a very low one, then Bob probably won't have a high reputation with Caroll, as the amount of fees he forwards to Caroll is smaller than the damage he can create. That is, if Caroll is a huge node and Bob is a raspberry pi, then Bob will never have a good reputation with Caroll. If they have similar *reputation_revenue*, then getting a good reputation with Bob is as difficult as getting a good reputation with Caroll. In your example (if I got it correctly) Bob's *reputation_revenue* = 1,000, *reputation_window*=100 and *routing_window*=10. Could you explain what are Caroll's parameters are in your example? The *fee_base_msat* does not indicate Carolls *reputation_revenue* (unless Alice is the only one transacting on the Bob-Caroll channel, and then she is the one paying for Bob's reputation). That being said, we use *reputation_revenue *to estimate the damage an attacker can create. If there is a chain of nodes that have high reputation with each other, and they are jammed, they would be compensated for the revenue lost during the attack. If Bob finds that having a high reputation with Caroll is crucial and 1,000 sats will not compensate him for loosing it, then he should either never endorse anything on that channel, or at least put a higher bar than *reputation_revenue*. There is an independent new observation on the effect of dynamic reputation > windows on payment reliability, as those windows are not announced to the > rest of the network, sudden changes in the links throughput based on HTLC > resolution might break the historical liquidity buckets of routing scoring > algorithms (at least in the way we're doing it for LDK), I think ? > Not sure what you mean by that. Best, Clara > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation
Hi all, > That is, one cannot gain reputation during low fee times and use it when fees are high. > Good reputation is also a function of the general environment, and so if there is a fee spike, reputation will change. It is true that nodes can go rogue, but this is why we aim > for the price of a good reputation to be similar to the amount of damage they can create. The lack of transitivity of the reputation acquisition cost (e.g based on historical fees earned from forwards originating from the peer) between the hops of the payment path still raises a vulnerability issue for the endorsement scheme, I think. Namely, let's say you have Alice, Bob and Caroll where endorsement has been obtained by Alice on the Bob incoming link by paying fees for an amount of 1000 sats for the last 100 blocks. Caroll offers a far higher pricing on her incoming link from Bob, 1 sats as `fee_base_msat` on her endorsed slots. It sounds to me there is nothing preventing Alice from sacrificing her earned reputation to inflict a loss of routing fees damage on Caroll incoming link ? Generally, I think the endorsement scheme assumes some synchronicity in the setting of routing fees by the hops. In practice, it's expected there will be variations based on their own pricing of liquidity, their accumulated data sets (e.g historical view of LN gossips) and downstream link topology. And this is the same between building a mitigation on concepts like "peace/war" time, sophisticated attackers might be able to mask their traffic as some spontaneous congestion. There is an independent new observation on the effect of dynamic reputation windows on payment reliability, as those windows are not announced to the rest of the network, sudden changes in the links throughput based on HTLC resolution might break the historical liquidity buckets of routing scoring algorithms (at least in the way we're doing it for LDK), I think ? Best, Antoine Le mer. 10 mai 2023 à 16:59, Clara Shikhelman a écrit : > Hi Christian, > > Thanks for your comments! We will discuss this further in the upcoming > call on the 15th, would be great to see you there! > > >> this is an intrinsic issue with reputation systems, and the main >> reason I'm sceptical w.r.t. their usefulness in lightning. >> Fundamentally any reputation system bases their expectations for the >> future on experiences they made in the past, and they are thus always >> susceptible to sudden behavioral changes (going rogue from a prior >> clean record) and whitewashing attacks (switching identity, abusing >> any builtin bootstrapping method for new users to gain a good or >> neutral reputation before turning rogue repeatedly). >> > > In the Lightning Network, fees are a native way to put a price on having a > good reputation (see details here [0]). In the design that we suggest, the > reputation gained today cannot be used in the distant future, and funds > need to be invested continuously to keep a good reputation. Good reputation > is also a function of the general environment, and so if there is a fee > spike, reputation will change. It is true that nodes can go rogue, but this > is why we aim for the price of a good reputation to be similar to the > amount of damage they can create. > > >> This gets compounded as soon as we start gossiping about reputations, >> since now our decisions are no longer based just on information we can >> witness ourselves, or at least verify its correctness, and as such an >> attacker can most likely "earn" a positive reputation in some other >> part of the world, and then turn around and attack the nodes that >> trusted the reputation shared from those other parts. >> > > Notice that we are not gossiping about our peer's reputation. The only > thing that a node communicates to its neighbor is whether they see an HTLC > as endorsed or just neutral, that is, should this HTLC be granted access to > all of the resources or just the restricted part. > > >> I'd be very interested in how many repeat interactions nodes get from >> individual senders, since that also tells us how much use we can get >> out of local-only reputation based systems, and I wouldn't be >> surprised if, for large routing nodes, we have sufficient data for >> them to make an informed decision, while the edges may be more >> vulnerable, but they'd also be used by way fewer senders, and the >> impact of an attack would also be proportionally smaller. >> > > This is something we hope to learn once we'll start collecting data from > our brave volunteers :) > > Cheers, > Clara > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation
> Re [3] > > I think with some implementation like cln we can write an extension > > an deploy in some nodes, I need to go deeper into it but I can help > > with this. But I would love to discuss how I can help with some > > implementation details. > > An experimental data gathering mechanism for CLN would be great! Seems > like lnmetrics would be a good home for it - I’ll follow up with you > when we start working on data collection. I am also planning to make a ML post regarding lnmetrics, but I will happy to talk more about the data that we need to get some useful data from the network. Cheers. Vincent. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation
Hi all, Pulling together a few conversation threads here. I’ve also updated the draft spec PR [1] with a full write up of the reputation scheme we’re proposing to help clarify open questions. TL;DR 1. Reputation is tracked locally for each of a node’s peers, there is *no gossip component*. 2. During a jamming attack, the less active edges of the network will experience gradually degraded quality of service, but they will be unaffected in times of peace. 3. Reputation is slow and expensive to build (accumulated through payment of fees) and fast to degrade, so sudden changes in behavior are short-lived. 4. Good reputation is always examined relative to a node’s recent routing activity, so reputation gained cheaply in the past during low-activity periods can’t be exploited in busier times. Re [2] > I'd be very interested in how many repeat interactions nodes get from individual senders, since that also tells us how much use we can get out of local-only reputation based systems, and I wouldn't be surprised if, for large routing nodes, we have sufficient data for them to make an informed decision, while the edges may be more vulnerable, but they'd also be used by way fewer senders, and the impact of an attack would also be proportionally smaller. I’m unclear on what you mean by “individual senders” here? In our scheme, nodes only track local reputation for their direct peers so what matters is their history with all HTLCs a peer has forwarded to them (not whether they come from repeat senders). It’s true that nodes that forward fewer HTLCs are less likely to be able to build a good reputation with very active routing nodes. In the regular operation of the network, this should have low to no impact on their activity - they don’t require much from their peers anyway. During an attack, small and low activity nodes will temporarily be in competition for large routing nodes’ scarce liquidity and slots, but will still be able to interact with similar nodes where they have better chances of building a good reputation. Re [3] > I think with some implementation like cln we can write an extension > an deploy in some nodes, I need to go deeper into it but I can help > with this. But I would love to discuss how I can help with some > implementation details. An experimental data gathering mechanism for CLN would be great! Seems like lnmetrics would be a good home for it - I’ll follow up with you when we start working on data collection. Cheers, Carla + Clara [1] https://github.com/lightning/bolts/pull/1071 [2] https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003944.html [3] https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003949.html On Wed, May 10, 2023 at 7:58 AM Christian Decker wrote: > Hi Antoine, > > this is an intrinsic issue with reputation systems, and the main > reason I'm sceptical w.r.t. their usefulness in lightning. > Fundamentally any reputation system bases their expectations for the > future on experiences they made in the past, and they are thus always > susceptible to sudden behavioral changes (going rogue from a prior > clean record) and whitewashing attacks (switching identity, abusing > any builtin bootstrapping method for new users to gain a good or > neutral reputation before turning rogue repeatedly). > > This gets compounded as soon as we start gossiping about reputations, > since now our decisions are no longer based just on information we can > witness ourselves, or at least verify its correctness, and as such an > attacker can most likely "earn" a positive reputation in some other > part of the world, and then turn around and attack the nodes that > trusted the reputation shared from those other parts. > > I'd be very interested in how many repeat interactions nodes get from > individual senders, since that also tells us how much use we can get > out of local-only reputation based systems, and I wouldn't be > surprised if, for large routing nodes, we have sufficient data for > them to make an informed decision, while the edges may be more > vulnerable, but they'd also be used by way fewer senders, and the > impact of an attack would also be proportionally smaller. > > Cheers, > Christian > > On Mon, May 8, 2023 at 10:26 PM Antoine Riard > wrote: > > > > Hi *, > > > > > Our suggestion is to start simple with a binary endorsement field. As > > > we learn more, we will be better equipped to understand whether a > > > more expressive value is required. > > > > I think the HTLC endorsement scheme as proposed is still suffering from > a vulnerability as local reputation can be built up during periods of low > routing fees, endorsement gained and then abused during periods of high > routing fees. Therefore, it sounds to me this scheme should aim for some > reputational transitivity between incoming traffic and outgoing traffic. > Namely, the acquisition cost of the local reputation should be equal to the > max timevalue damage that one
Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation
Hi all, > > This gets compounded as soon as we start gossiping about reputations, > > since now our decisions are no longer based just on information we can > > witness ourselves, or at least verify its correctness, and as such an > > attacker can most likely "earn" a positive reputation in some other > > part of the world, and then turn around and attack the nodes that > > trusted the reputation shared from those other parts. > > > > Notice that we are not gossiping about our peer's reputation. The only > thing that a node communicates to its neighbor is whether they see an HTLC > as endorsed or just neutral, that is, should this HTLC be granted access to Yeah, this is a good point. If we gossip this information, we may see different values for the same node, and I'm sure someone will propose a "proof who is telling the true" for this. I don't want the reputation we end up with to be gossiped to our peers. In my last research on this, I noted that some nodes with Tor have a completely unrealistic vision of the network. They believe that other nodes are offline, but the problem is actually the overloaded Tor network. Cheers! Vincent ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation
Hi all, > Some updates on channel jamming! > > # Next Call > - Monday 01 May @ 15:00 UTC > - https://meet.jit.si/UnjammingLN > - Agenda: https://github.com/ClaraShk/LNJamming/issues/12 > > # Data Gathering > During these weekly calls, we've come to agreement that we would like > to gather data about the use of HTLC endorsement and local reputation > tracking for jamming mitigation. A reminder of the full scheme is > included at the end of this email, and covered more verbosely in [1]. > > We have a few goals in mind: > - Observe the effect of endorsement in the steady state with > logging-only implementation. > - Gather real-world data for use in future simulation work. There is anything that I can do to help here with lnmetrics tools? With some guidance (because i lost the track of the situation here) I can be able to deploy a metrics collector in production by the end of May. > - Experiment with different algorithms for tracking local reputation. > > The minimal changes required to add HTLC endorsement are outlined in [2]. > Our suggestion is to start simple with a binary endorsement field. As > we learn more, we will be better equipped to understand whether a > more expressive value is required. > > We'd be interested to hear whether there's any appetite to deploy using > an experimental TLV value? > > # Reputation Scheme > - Each node locally tracks the reputation of its direct neighbors. > - Each node allocates, per its risk tolerance: > - A number of slots reserved for endorsed HTLCs from high reputation > peers. > - A portion of liquidity reserved for endorsed HTLCs from high > reputation peers. > - Forwarding of HTLCs: > - If a HTLC is endorsed by a high reputation peer, it is forwarded > as usual with endorsed = 1. > - Otherwise, it is forwarded with endorsed = 0 if there are slots and > liquidity available for unknown HTLCs. > > Endorsement and reputation are proposed as the first step in a two part > scheme for mitigating channel jamming: > - Reputation for slow jams which are easily detected as misbehavior. > - Unconditional fees for quick jams that are difficult to detect, as > they can always fall under a target threshold. Why not? I think this deserve a round on the real network also because it is hard to simulat the real network imho, and I think with some implementation like cln we can write an extention an deploy it in some nodes, I need to go deeper into it but I can help with this. > Looking forward to discussing further in the upcoming call! Unfortunatlly I ran out of routing here :) but I would love to discuss how I can help with some implementation details. Thanks to update in a very compact way what it is going on in the Jamming mitigating meetins, it is helping a lot. Cheers! Vincent. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation
Hi Christian, Thanks for your comments! We will discuss this further in the upcoming call on the 15th, would be great to see you there! > this is an intrinsic issue with reputation systems, and the main > reason I'm sceptical w.r.t. their usefulness in lightning. > Fundamentally any reputation system bases their expectations for the > future on experiences they made in the past, and they are thus always > susceptible to sudden behavioral changes (going rogue from a prior > clean record) and whitewashing attacks (switching identity, abusing > any builtin bootstrapping method for new users to gain a good or > neutral reputation before turning rogue repeatedly). > In the Lightning Network, fees are a native way to put a price on having a good reputation (see details here [0]). In the design that we suggest, the reputation gained today cannot be used in the distant future, and funds need to be invested continuously to keep a good reputation. Good reputation is also a function of the general environment, and so if there is a fee spike, reputation will change. It is true that nodes can go rogue, but this is why we aim for the price of a good reputation to be similar to the amount of damage they can create. > This gets compounded as soon as we start gossiping about reputations, > since now our decisions are no longer based just on information we can > witness ourselves, or at least verify its correctness, and as such an > attacker can most likely "earn" a positive reputation in some other > part of the world, and then turn around and attack the nodes that > trusted the reputation shared from those other parts. > Notice that we are not gossiping about our peer's reputation. The only thing that a node communicates to its neighbor is whether they see an HTLC as endorsed or just neutral, that is, should this HTLC be granted access to all of the resources or just the restricted part. > I'd be very interested in how many repeat interactions nodes get from > individual senders, since that also tells us how much use we can get > out of local-only reputation based systems, and I wouldn't be > surprised if, for large routing nodes, we have sufficient data for > them to make an informed decision, while the edges may be more > vulnerable, but they'd also be used by way fewer senders, and the > impact of an attack would also be proportionally smaller. > This is something we hope to learn once we'll start collecting data from our brave volunteers :) Cheers, Clara ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation
From my perspective it really comes down to whether you want security *guarantees* or data to assist you in making probabilistic judgments about future behavior. Reputation data or reputation systems will never give you guarantees for the reasons Christian explains. But reputation data is better than nothing and depending on the quality and granularity of the data could be considerably better than nothing. In the most basic case of deciding on a potential channel counterparty I would much rather choose a counterparty who has demonstrated competence and reliability over a number of years than a channel counterparty who has just joined the network and who I know nothing about. Similarly a Lightning node that hasn't carried a jamming attack for multiple years despite having the opportunity to is a much better bet than a Lightning node of which I know nothing. Now where it sits on the software stack assuming a user opts into such a reputation "service" (plugin maybe or more likely an API) is I think what in essence this discussion is about. As I've already stated previously and which I agree with Christian on is that it isn't/shouldn't be a protocol or a P2P gossiping issue. In the same way as we have multiple Lightning explorers (1ML, Amboss etc) that aren't part of the Lightning protocol or part of the "core" of a Lightning node you can expect there would be competing reputation data providers and services. Also many users for privacy and/or other reasons won't be interested in using or participating in (to the extent they can opt out if the data is public) a reputation service. So yeah I think I'm somewhere in between Christian's and Antoine's perspectives here. I do think there are interesting projects, services or even businesses in this area of reputation but it isn't a protocol/P2P gossiping issue or a "core" of a Lightning node issue. Thanks Michael [0]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003766.html -- Michael Folkson Email: michaelfolkson at protonmail.com GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin --- Original Message --- On Wednesday, May 10th, 2023 at 12:57, Christian Decker wrote: > Hi Antoine, > > this is an intrinsic issue with reputation systems, and the main > reason I'm sceptical w.r.t. their usefulness in lightning. > Fundamentally any reputation system bases their expectations for the > future on experiences they made in the past, and they are thus always > susceptible to sudden behavioral changes (going rogue from a prior > clean record) and whitewashing attacks (switching identity, abusing > any builtin bootstrapping method for new users to gain a good or > neutral reputation before turning rogue repeatedly). > > This gets compounded as soon as we start gossiping about reputations, > since now our decisions are no longer based just on information we can > witness ourselves, or at least verify its correctness, and as such an > attacker can most likely "earn" a positive reputation in some other > part of the world, and then turn around and attack the nodes that > trusted the reputation shared from those other parts. > > I'd be very interested in how many repeat interactions nodes get from > individual senders, since that also tells us how much use we can get > out of local-only reputation based systems, and I wouldn't be > surprised if, for large routing nodes, we have sufficient data for > them to make an informed decision, while the edges may be more > vulnerable, but they'd also be used by way fewer senders, and the > impact of an attack would also be proportionally smaller. > > Cheers, > Christian > > On Mon, May 8, 2023 at 10:26 PM Antoine Riard antoine.ri...@gmail.com wrote: > > > Hi *, > > > > > Our suggestion is to start simple with a binary endorsement field. As > > > we learn more, we will be better equipped to understand whether a > > > more expressive value is required. > > > > I think the HTLC endorsement scheme as proposed is still suffering from a > > vulnerability as local reputation can be built up during periods of low > > routing fees, endorsement gained and then abused during periods of high > > routing fees. Therefore, it sounds to me this scheme should aim for some > > reputational transitivity between incoming traffic and outgoing traffic. > > Namely, the acquisition cost of the local reputation should be equal to the > > max timevalue damage that one can inflict on a routing node channel > > accessible from its local counterparty granting this high-level of > > reputation. > > > > I don't know if this can be fixed by ensuring permanent link-level "gossip" > > where counterparties along a payment path expose their reputation > > heuristics to guarantee this transitivity, or it's a fundamental issue with > > a point-to-point approach like HTLC endorsement. > > > > Opened an issue on the repository to
Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation
Hi Antoine, this is an intrinsic issue with reputation systems, and the main reason I'm sceptical w.r.t. their usefulness in lightning. Fundamentally any reputation system bases their expectations for the future on experiences they made in the past, and they are thus always susceptible to sudden behavioral changes (going rogue from a prior clean record) and whitewashing attacks (switching identity, abusing any builtin bootstrapping method for new users to gain a good or neutral reputation before turning rogue repeatedly). This gets compounded as soon as we start gossiping about reputations, since now our decisions are no longer based just on information we can witness ourselves, or at least verify its correctness, and as such an attacker can most likely "earn" a positive reputation in some other part of the world, and then turn around and attack the nodes that trusted the reputation shared from those other parts. I'd be very interested in how many repeat interactions nodes get from individual senders, since that also tells us how much use we can get out of local-only reputation based systems, and I wouldn't be surprised if, for large routing nodes, we have sufficient data for them to make an informed decision, while the edges may be more vulnerable, but they'd also be used by way fewer senders, and the impact of an attack would also be proportionally smaller. Cheers, Christian On Mon, May 8, 2023 at 10:26 PM Antoine Riard wrote: > > Hi *, > > > Our suggestion is to start simple with a binary endorsement field. As > > we learn more, we will be better equipped to understand whether a > > more expressive value is required. > > I think the HTLC endorsement scheme as proposed is still suffering from a > vulnerability as local reputation can be built up during periods of low > routing fees, endorsement gained and then abused during periods of high > routing fees. Therefore, it sounds to me this scheme should aim for some > reputational transitivity between incoming traffic and outgoing traffic. > Namely, the acquisition cost of the local reputation should be equal to the > max timevalue damage that one can inflict on a routing node channel > accessible from its local counterparty granting this high-level of reputation. > > I don't know if this can be fixed by ensuring permanent link-level "gossip" > where counterparties along a payment path expose their reputation heuristics > to guarantee this transitivity, or it's a fundamental issue with a > point-to-point approach like HTLC endorsement. > > Opened an issue on the repository to converge on a threat model: > https://github.com/ClaraShk/LNJamming/pull/13 > > I still think building data gathering infrastructure for Lightning is > valuable as ultimately any jamming mitigation will have to adapt its upfront > fees or reputation acquisition cost in function of HTLC traffic and market > forces. > > Looking forward to giving an update on Staking Credentials [0], an end-to-end > approach to mitigate channel jamming. > > Best, > Antoine > > [0] > https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003754.html > > Le dim. 30 avr. 2023 à 03:57, Carla Kirk-Cohen a écrit > : >> >> Hi list, >> >> Some updates on channel jamming! >> >> # Next Call >> - Monday 01 May @ 15:00 UTC >> - https://meet.jit.si/UnjammingLN >> - Agenda: https://github.com/ClaraShk/LNJamming/issues/12 >> >> # Data Gathering >> During these weekly calls, we've come to agreement that we would like >> to gather data about the use of HTLC endorsement and local reputation >> tracking for jamming mitigation. A reminder of the full scheme is >> included at the end of this email, and covered more verbosely in [1]. >> >> We have a few goals in mind: >> - Observe the effect of endorsement in the steady state with >> logging-only implementation. >> - Gather real-world data for use in future simulation work. >> - Experiment with different algorithms for tracking local reputation. >> >> The minimal changes required to add HTLC endorsement are outlined in [2]. >> Our suggestion is to start simple with a binary endorsement field. As >> we learn more, we will be better equipped to understand whether a >> more expressive value is required. >> >> With this infrastructure in place, we can start to experiment with >> various local reputation schemes and data gathering, possibly even >> externally to LN implementations in projects like circuitbreaker [3]. >> We'd be interested to hear whether there's any appetite to deploy using >> an experimental TLV value? >> >> # Reputation Scheme >> - Each node locally tracks the reputation of its direct neighbors. >> - Each node allocates, per its risk tolerance: >> - A number of slots reserved for endorsed HTLCs from high reputation >> peers. >> - A portion of liquidity reserved for endorsed HTLCs from high >> reputation peers. >> - Forwarding of HTLCs: >> - If a HTLC is endorsed by a high reputation peer, it is forwarded >>
Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation
Hi, I think the HTLC endorsement scheme as proposed is still suffering from a > vulnerability as local reputation can be built up during periods of low > routing fees, endorsement gained and then abused during periods of high > routing fees. Therefore, it sounds to me this scheme should aim for some > reputational transitivity between incoming traffic and outgoing traffic. > Namely, the acquisition cost of the local reputation should be equal to the > max timevalue damage that one can inflict on a routing node channel > accessible from its local counterparty granting this high-level of > reputation. > This is the reason we have a moving window for the calculation. Note that if there is a channel between Alice and Bob, then the reputation of Alice from Bob's point of view is a function of Bob's total revenue in the latest time period. If Bob experiences a spike in routing fees, nodes might lose their reputation, but it would not work the other way around. That is, one cannot gain reputation during low fee times and use it when fees are high. See further details in this email [0] Best, Clara [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-February/003857.html ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation
Hi *, > Our suggestion is to start simple with a binary endorsement field. As > we learn more, we will be better equipped to understand whether a > more expressive value is required. I think the HTLC endorsement scheme as proposed is still suffering from a vulnerability as local reputation can be built up during periods of low routing fees, endorsement gained and then abused during periods of high routing fees. Therefore, it sounds to me this scheme should aim for some reputational transitivity between incoming traffic and outgoing traffic. Namely, the acquisition cost of the local reputation should be equal to the max timevalue damage that one can inflict on a routing node channel accessible from its local counterparty granting this high-level of reputation. I don't know if this can be fixed by ensuring permanent link-level "gossip" where counterparties along a payment path expose their reputation heuristics to guarantee this transitivity, or it's a fundamental issue with a point-to-point approach like HTLC endorsement. Opened an issue on the repository to converge on a threat model: https://github.com/ClaraShk/LNJamming/pull/13 I still think building data gathering infrastructure for Lightning is valuable as ultimately any jamming mitigation will have to adapt its upfront fees or reputation acquisition cost in function of HTLC traffic and market forces. Looking forward to giving an update on Staking Credentials [0], an end-to-end approach to mitigate channel jamming. Best, Antoine [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003754.html Le dim. 30 avr. 2023 à 03:57, Carla Kirk-Cohen a écrit : > Hi list, > > Some updates on channel jamming! > > # Next Call > - Monday 01 May @ 15:00 UTC > - https://meet.jit.si/UnjammingLN > - Agenda: https://github.com/ClaraShk/LNJamming/issues/12 > > # Data Gathering > During these weekly calls, we've come to agreement that we would like > to gather data about the use of HTLC endorsement and local reputation > tracking for jamming mitigation. A reminder of the full scheme is > included at the end of this email, and covered more verbosely in [1]. > > We have a few goals in mind: > - Observe the effect of endorsement in the steady state with > logging-only implementation. > - Gather real-world data for use in future simulation work. > - Experiment with different algorithms for tracking local reputation. > > The minimal changes required to add HTLC endorsement are outlined in [2]. > Our suggestion is to start simple with a binary endorsement field. As > we learn more, we will be better equipped to understand whether a > more expressive value is required. > > With this infrastructure in place, we can start to experiment with > various local reputation schemes and data gathering, possibly even > externally to LN implementations in projects like circuitbreaker [3]. > We'd be interested to hear whether there's any appetite to deploy using > an experimental TLV value? > > # Reputation Scheme > - Each node locally tracks the reputation of its direct neighbors. > - Each node allocates, per its risk tolerance: > - A number of slots reserved for endorsed HTLCs from high reputation > peers. > - A portion of liquidity reserved for endorsed HTLCs from high > reputation peers. > - Forwarding of HTLCs: > - If a HTLC is endorsed by a high reputation peer, it is forwarded > as usual with endorsed = 1. > - Otherwise, it is forwarded with endorsed = 0 if there are slots and > liquidity available for unknown HTLCs. > > Endorsement and reputation are proposed as the first step in a two part > scheme for mitigating channel jamming: > - Reputation for slow jams which are easily detected as misbehavior. > - Unconditional fees for quick jams that are difficult to detect, as > they can always fall under a target threshold. > > Looking forward to discussing further in the upcoming call! > > Best, > Carla and Clara > > [1] https://gist.github.com/carlaKC/be820bb638624253f3ae7b39dbd0e343 > [2] https://github.com/lightning/bolts/pull/1071 > [3] https://github.com/lightningequipment/circuitbreaker > ___ > 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
[Lightning-dev] HTLC Endorsement for Jamming Mitigation
Hi list, Some updates on channel jamming! # Next Call - Monday 01 May @ 15:00 UTC - https://meet.jit.si/UnjammingLN - Agenda: https://github.com/ClaraShk/LNJamming/issues/12 # Data Gathering During these weekly calls, we've come to agreement that we would like to gather data about the use of HTLC endorsement and local reputation tracking for jamming mitigation. A reminder of the full scheme is included at the end of this email, and covered more verbosely in [1]. We have a few goals in mind: - Observe the effect of endorsement in the steady state with logging-only implementation. - Gather real-world data for use in future simulation work. - Experiment with different algorithms for tracking local reputation. The minimal changes required to add HTLC endorsement are outlined in [2]. Our suggestion is to start simple with a binary endorsement field. As we learn more, we will be better equipped to understand whether a more expressive value is required. With this infrastructure in place, we can start to experiment with various local reputation schemes and data gathering, possibly even externally to LN implementations in projects like circuitbreaker [3]. We'd be interested to hear whether there's any appetite to deploy using an experimental TLV value? # Reputation Scheme - Each node locally tracks the reputation of its direct neighbors. - Each node allocates, per its risk tolerance: - A number of slots reserved for endorsed HTLCs from high reputation peers. - A portion of liquidity reserved for endorsed HTLCs from high reputation peers. - Forwarding of HTLCs: - If a HTLC is endorsed by a high reputation peer, it is forwarded as usual with endorsed = 1. - Otherwise, it is forwarded with endorsed = 0 if there are slots and liquidity available for unknown HTLCs. Endorsement and reputation are proposed as the first step in a two part scheme for mitigating channel jamming: - Reputation for slow jams which are easily detected as misbehavior. - Unconditional fees for quick jams that are difficult to detect, as they can always fall under a target threshold. Looking forward to discussing further in the upcoming call! Best, Carla and Clara [1] https://gist.github.com/carlaKC/be820bb638624253f3ae7b39dbd0e343 [2] https://github.com/lightning/bolts/pull/1071 [3] https://github.com/lightningequipment/circuitbreaker ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
