Re: [Lightning-dev] Local Reputation to Mitigate Slow Jamming
Hi, This is unclear on which criterias the endorsement decision is made > A node endorses an HTLC if and only if it came from a neighbour that has reputation 1 that endorsed it. > Additionally, this is unclear how the available liquidity/slots on a given > outbound channel are initially distributed between all the inbound channels > (e.g proportional to the capacity) and how they're balanced once the > inbound channels start to accumulate reputation. > The quotas are for any incoming HTLC that is either from a neighbour with reputation 0, or is not endorsed. For each channel, the quotas are independent of other channels and independent of the neighbour that forwarded the HTLC. > I don't know if this local reputation scheme precises how reputation is > slashed in case of HTLC failure, and if any "grace" amount/rate is granted > to the inbound channel counterparty, e.g Alice. > > Independently of those considerations, I think this local reputation > scheme might suffer from exploitable reputation asymmetries by a jamming > adversary. > Let's say you have the topology: > > Alice - Bob - Caroll - Dave > > Alice accumulated a reputation of 1 towards Bob and same for Bob towards > Caroll. As `fee_base_msat` Bob picked up 1000 msat and Caroll picked up > 2000 msat. If Alice forwards a HTLC to Bob and it is endorsed by him > before relay to Caroll, Alice can now inflict a 50 sat damage to Caroll, > while only encumbering the lower-priced reputational cost towards Bob. > > This concern could hold in case of asymmetries arising from the dynamic > adjustment of routing fees during an evaluated period of time. E.g both Bob > and Caroll requires routing fees of 1000 msat. Alice builds up a reputation > of 1 towards Bob during this period N. At period N+1, Caroll bumps her > routing fees to 2000 msat. From now on, Alice can exploit this asymmetry. > In general, if Bob is a low flow node (resulting in it having a low threshold for reputation), he cannot have a high reputation with Carroll as he will never forward enough. Taking into account the differences in fees is interesting, but should be checked further. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Local Reputation to Mitigate Slow Jamming
Hi all, My understanding of the local reputation channel is the following, when Bob receives a HTLC forwarding request from Alice to Caroll: - if Alice has reputation of 1 and Alice endorses the transaction, Bob forwards and endorses the HTLC to Caroll - else if the HTLC amount is under the available outbound liquidity quota assigned to Alice and available outbound slots assigned to Alice, Bob forwards the HTLC to Caroll and reduce available outbound liquidity/slots assigned to Alice - else the HTLC is rejected This is unclear on which criterias the endorsement decision is made (e.g CLTV expiry delta, odds of settlement, ongoing congestion of outbound channels ?). Additionally, this is unclear how the available liquidity/slots on a given outbound channel are initially distributed between all the inbound channels (e.g proportional to the capacity) and how they're balanced once the inbound channels start to accumulate reputation. I don't know if this local reputation scheme precises how reputation is slashed in case of HTLC failure, and if any "grace" amount/rate is granted to the inbound channel counterparty, e.g Alice. Independently of those considerations, I think this local reputation scheme might suffer from exploitable reputation asymmetries by a jamming adversary. Let's say you have the topology: Alice - Bob - Caroll - Dave Alice accumulated a reputation of 1 towards Bob and same for Bob towards Caroll. As `fee_base_msat` Bob picked up 1000 msat and Caroll picked up 2000 msat. If Alice forwards a HTLC to Bob and it is endorsed by him before relay to Caroll, Alice can now inflict a 50 sat damage to Caroll, while only encumbering the lower-priced reputational cost towards Bob. This concern could hold in case of asymmetries arising from the dynamic adjustment of routing fees during an evaluated period of time. E.g both Bob and Caroll requires routing fees of 1000 msat. Alice builds up a reputation of 1 towards Bob during this period N. At period N+1, Caroll bumps her routing fees to 2000 msat. From now on, Alice can exploit this asymmetry. While I think this deficiency could be fixed by ensuring a proportionality of the reputation acquisition cost between the inbound channels and the cost requested by a counterparty on an outbound channel, I believe this would come with the downside that any update in reputation cost should be recursively applied to the downstream links (i.e Bob on Alice channel, Alice on neighbouring inbound channels, etc). Apart of this reputation asymmetry concern, I think the local reputation scheme could suffer from spontaneous jamming by "honest" long-term held packets (e.g CLTV delta=2 weeks), where even if Alice is not scored to 1 by Bob, she always settles her long-term held packets. However, those packets are yielding less routing fees to Bob than let's say 14 HTLC packets of CLTV delta = 1 day. Finally, the dynamic reduction of the available outbound liquidity/slots in the occurrence of reputation=0 counterparty's HTLC being only known at the link-level could break the expectations of the HTLC senders scoring algorithms. E.g, being connected to Alice might have probed through another path the available liquidity on the link Bob-Caroll. This Eve's probe is falsified by any reduction done by Caroll towards Bob, and therefore Eve's payment reliability is likely to be downgraded. Best, Antoine Le jeu. 16 févr. 2023 à 21:29, Clara Shikhelman a écrit : > Hi List, > > We’re writing to seek early feedback on a draft for a neighbour reputation > setting recommendation as a jamming mitigation. The main idea is that > allowing full access to liquidity and slots in a channel can result in > jamming. To prevent this, we allow full access only to neighbours that > forward HTLC that resolve quickly and generate more profit than the damage > they can potentially create. > > The full suggested jamming mitigation solution includes upfront fees > together with reputation, see [1] for details. > > In the previous episodes: > > As presented here [1], we suggest a two part jamming mitigation strategy. > Reputation-based forwarding is aimed to solve “slow jamming”, where the > jamming transaction takes a long time to resolve. > > The main idea is that each node gives a binary reputation to its > neighbour. Each channel has a quota of liquidity and slots (say 50% of the > channel size and 50% of the slots in the channel) dedicated to transactions > coming from neighbours with reputation 0, or for transactions coming from > neighbours with reputation 1 that were not endorsed by the neighbour. > > For example, when Alice asks Bob to forward to Charlie then: > > If (Alice has reputation 1 with Bob) and (Alice endorses transaction): > > Forward and endorse > > Else: > > If (amount < available liquidity quota) and (available slots in quota>0): > > Forward HTLC without endorsing > > Reduce available liquidity and slots > > Else: > > Reject > > Reputation: > > The question we discuss here is h
Re: [Lightning-dev] Local Reputation to Mitigate Slow Jamming
Hi all, Sorry if I jump in the middle of the party! > Could you explain the benefits of continuous solutions over binary? This is > something we should definitely understand before going in a more > complicated direction. I completly agree! Why we will not propose an practical definition of the local reputation and we ran some experimentation of how the local metrics is evaluated in a real environment with a real LN node? By now we should have the tools to conduct this analysis. Cheers! Vincent. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Local Reputation to Mitigate Slow Jamming
> With a binary solution a single attacker can easily fill your quota of > low-confidence HTLCs and then all low-reputation nodes are blocked. But not > all of them are attackers, some of them just don't send you enough traffic > to get a high reputation for instance and you're going to block them too. > With a continuous solution you can differentiate between an active attacker > and someone who just sends to nodes with poor connectivity and only block > the first. > If it's very cheap to behave like a neighbour with poor connectivity, why wouldn't the attacker mimic this, and then block? Differentiating between a potential attacker and just a low-traffic neighbour is very difficult. I think that instead of "low/high reputation" a better way to think about it is "unknown/endorsed", and just consider which neighbour needs access to all resources and which one doesn't. The idea of different bins was brought up a few times and might help a bit, but I am not sure at all that it is worth the complication. For reporting c truthfully, if you report it too high you will be penalized > by having your reputation lowered, if you report it too low you will > penalize your HTLCs and still get the same reputation as if you had > reported it truthfully. > It might be that there is a strong motivation to underestimate than overestimate. That is – the punishment for underestimating by X is significantly smaller than for overestimating by X (or vice versa). The formula you choose can affect this significantly. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Local Reputation to Mitigate Slow Jamming
The benefit is that you can be more precise when blocking. With a binary solution a single attacker can easily fill your quota of low-confidence HTLCs and then all low-reputation nodes are blocked. But not all of them are attackers, some of them just don't send you enough traffic to get a high reputation for instance and you're going to block them too. With a continuous solution you can differentiate between an active attacker and someone who just sends to nodes with poor connectivity and only block the first. For reporting c truthfully, if you report it too high you will be penalized by having your reputation lowered, if you report it too low you will penalize your HTLCs and still get the same reputation as if you had reported it truthfully. Le ven. 3 mars 2023 à 19:45, Clara Shikhelman a écrit : > Could you explain the benefits of continuous solutions over binary? This > is something we should definitely understand before going in a more > complicated direction. > > Also, I'm still not sure that the rational behaviour is to report *c* > truthfully. > > > > On Fri, Mar 3, 2023 at 11:51 AM Thomas HUET wrote: > >> By giving a high confidence to HTLCs you increase the chance that they >> are relayed which should be your goal. Having a high reputation is not a >> goal in itself, it's just a way to make your HTLCs more likely to be >> relayed. If you always report confidence 0, then yes you will have a >> reputation of 1 but your HTLCs will still be rejected at the first sign of >> congestion. >> >> Le ven. 3 mars 2023 à 17:14, Clara Shikhelman >> a écrit : >> >>> Hi Thomas, >>> >>> Thanks for the example. >>> >>> - If c < p then yes it gives it a higher reputation but the reputation is capped at 1 anyway, so by underestimating the confidence the node doesn't gain anything. >>> Is there anything to gain from giving high confidence? By doing this, >>> you risk lowering your reputation, and it's not clear what you gain. >>> Could it be that the best selfish strategy is to report confidence 0 >>> (that maps to reputation 1) all the time? >>> >> ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Local Reputation to Mitigate Slow Jamming
Could you explain the benefits of continuous solutions over binary? This is something we should definitely understand before going in a more complicated direction. Also, I'm still not sure that the rational behaviour is to report *c* truthfully. On Fri, Mar 3, 2023 at 11:51 AM Thomas HUET wrote: > By giving a high confidence to HTLCs you increase the chance that they are > relayed which should be your goal. Having a high reputation is not a goal > in itself, it's just a way to make your HTLCs more likely to be relayed. If > you always report confidence 0, then yes you will have a reputation of 1 > but your HTLCs will still be rejected at the first sign of congestion. > > Le ven. 3 mars 2023 à 17:14, Clara Shikhelman > a écrit : > >> Hi Thomas, >> >> Thanks for the example. >> >> - If c < p then yes it gives it a higher reputation but the reputation is >>> capped at 1 anyway, so by underestimating the confidence the node doesn't >>> gain anything. >>> >> Is there anything to gain from giving high confidence? By doing this, you >> risk lowering your reputation, and it's not clear what you gain. >> Could it be that the best selfish strategy is to report confidence 0 >> (that maps to reputation 1) all the time? >> > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Local Reputation to Mitigate Slow Jamming
By giving a high confidence to HTLCs you increase the chance that they are relayed which should be your goal. Having a high reputation is not a goal in itself, it's just a way to make your HTLCs more likely to be relayed. If you always report confidence 0, then yes you will have a reputation of 1 but your HTLCs will still be rejected at the first sign of congestion. Le ven. 3 mars 2023 à 17:14, Clara Shikhelman a écrit : > Hi Thomas, > > Thanks for the example. > > - If c < p then yes it gives it a higher reputation but the reputation is >> capped at 1 anyway, so by underestimating the confidence the node doesn't >> gain anything. >> > Is there anything to gain from giving high confidence? By doing this, you > risk lowering your reputation, and it's not clear what you gain. > Could it be that the best selfish strategy is to report confidence 0 (that > maps to reputation 1) all the time? > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Local Reputation to Mitigate Slow Jamming
Hi Thomas, Thanks for the example. - If c < p then yes it gives it a higher reputation but the reputation is > capped at 1 anyway, so by underestimating the confidence the node doesn't > gain anything. > Is there anything to gain from giving high confidence? By doing this, you risk lowering your reputation, and it's not clear what you gain. Could it be that the best selfish strategy is to report confidence 0 (that maps to reputation 1) all the time? ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Local Reputation to Mitigate Slow Jamming
To give a very simple example, imagine a node that sends the same confidence c for all HTLCs. We want c to be equal to the probability p that its HTLCs succeed. - If c = p then all is well and we give a reputation of 1 to the node. - If c > p then this node is overconfident or is lying to have its HTLCs relayed, in both cases we should lower its reputation to account for that. - If c < p then yes it gives it a higher reputation but the reputation is capped at 1 anyway, so by underestimating the confidence the node doesn't gain anything. Ideally we want all honest nodes to have a reputation of 1. It doesn't mean that all their HTLCs succeed, it just means that they provide reliable estimates of the success probability of the HTLCs. Le jeu. 2 mars 2023 à 19:57, Clara Shikhelman a écrit : > Hi Thomas, > > I really like the idea of taking into consideration the failures. In our > proposal, a failure won't benefit your reputation, as the neighbour is > trying to reach a fee threshold, but taking it into account instead of > ignoring it could be helpful against an adversary trying to manipulate > parameters. > > Could you elaborate a bit about "*c, the confidence given by the previous > node.*" It looks from the formula (that has *1/c* component) that the > lower the confidence, the higher the reputation, and I am not sure that > this is the goal. Some numerical examples could help clarify the dynamics > you are aiming for. > > Do you have some estimation of what kind of protection or compensation > this method offers? > > Best, > Clara > > On Thu, Mar 2, 2023 at 8:14 AM Thomas HUET wrote: > >> Hello, >> >> I think the local reputation is more important than upfront fees and >> should be worked on first because 1) the most likely attack against the >> network today is the slow jamming attack against which upfront fees are not >> very effective (an attacker would only consider fast jamming if the network >> is already resilient to slow jamming) and 2) I think that local reputation >> may protect well enough against all types of jamming so that we don't even >> need upfront fees to protect against fast jamming. >> Regarding the formula itself, I would treat all scores as continuous >> values between 0 and 1 instead of binary classes. My proposed formula is >> detailed here: >> >> https://docs.google.com/document/d/1hEt1EzyPFJ3gOY7PAvtm_XotTnlQO2r7LSF8Jx34qgc/edit?usp=sharing >> However my proposal is compatible with Clara's one in that the only thing >> that needs to be communicated to the peers is how confident we are that the >> payment will succeed and all the rest is done locally and everyone can use >> their own formula. I would just prefer this confidence value to be more >> than one bit but my formula would work with anything, even zero bits. The >> advantage of using more bits is that we can be more precise in which HTLCs >> we reject and reduce the number of innocent casualties. >> >> Thomas >> >> Le jeu. 16 févr. 2023 à 22:29, Clara Shikhelman < >> clara.shikhel...@gmail.com> a écrit : >> >>> Hi List, >>> >>> We’re writing to seek early feedback on a draft for a neighbour >>> reputation setting recommendation as a jamming mitigation. The main idea is >>> that allowing full access to liquidity and slots in a channel can result in >>> jamming. To prevent this, we allow full access only to neighbours that >>> forward HTLC that resolve quickly and generate more profit than the damage >>> they can potentially create. >>> >>> The full suggested jamming mitigation solution includes upfront fees >>> together with reputation, see [1] for details. >>> >>> In the previous episodes: >>> >>> As presented here [1], we suggest a two part jamming mitigation >>> strategy. Reputation-based forwarding is aimed to solve “slow jamming”, >>> where the jamming transaction takes a long time to resolve. >>> >>> The main idea is that each node gives a binary reputation to its >>> neighbour. Each channel has a quota of liquidity and slots (say 50% of the >>> channel size and 50% of the slots in the channel) dedicated to transactions >>> coming from neighbours with reputation 0, or for transactions coming from >>> neighbours with reputation 1 that were not endorsed by the neighbour. >>> >>> For example, when Alice asks Bob to forward to Charlie then: >>> >>> If (Alice has reputation 1 with Bob) and (Alice endorses transaction): >>> >>> Forward and endorse >>> >>> Else: >>> >>> If (amount < available liquidity quota) and (available slots in >>> quota>0): >>> >>> Forward HTLC without endorsing >>> >>> Reduce available liquidity and slots >>> >>> Else: >>> >>> Reject >>> >>> Reputation: >>> >>> The question we discuss here is how does Alice gain “good” reputation >>> (i.e., a score of 1). Alice starts at 0, and she gains and keeps her good >>> reputation of 1 by continuously paying more fees to Bob than the damage she >>> can inflict. >>> >>> The 3 main parameters for reputation that each node operator picks are S,L >>> and M. Our
Re: [Lightning-dev] Local Reputation to Mitigate Slow Jamming
Hi Thomas, I really like the idea of taking into consideration the failures. In our proposal, a failure won't benefit your reputation, as the neighbour is trying to reach a fee threshold, but taking it into account instead of ignoring it could be helpful against an adversary trying to manipulate parameters. Could you elaborate a bit about "*c, the confidence given by the previous node.*" It looks from the formula (that has *1/c* component) that the lower the confidence, the higher the reputation, and I am not sure that this is the goal. Some numerical examples could help clarify the dynamics you are aiming for. Do you have some estimation of what kind of protection or compensation this method offers? Best, Clara On Thu, Mar 2, 2023 at 8:14 AM Thomas HUET wrote: > Hello, > > I think the local reputation is more important than upfront fees and > should be worked on first because 1) the most likely attack against the > network today is the slow jamming attack against which upfront fees are not > very effective (an attacker would only consider fast jamming if the network > is already resilient to slow jamming) and 2) I think that local reputation > may protect well enough against all types of jamming so that we don't even > need upfront fees to protect against fast jamming. > Regarding the formula itself, I would treat all scores as continuous > values between 0 and 1 instead of binary classes. My proposed formula is > detailed here: > > https://docs.google.com/document/d/1hEt1EzyPFJ3gOY7PAvtm_XotTnlQO2r7LSF8Jx34qgc/edit?usp=sharing > However my proposal is compatible with Clara's one in that the only thing > that needs to be communicated to the peers is how confident we are that the > payment will succeed and all the rest is done locally and everyone can use > their own formula. I would just prefer this confidence value to be more > than one bit but my formula would work with anything, even zero bits. The > advantage of using more bits is that we can be more precise in which HTLCs > we reject and reduce the number of innocent casualties. > > Thomas > > Le jeu. 16 févr. 2023 à 22:29, Clara Shikhelman < > clara.shikhel...@gmail.com> a écrit : > >> Hi List, >> >> We’re writing to seek early feedback on a draft for a neighbour >> reputation setting recommendation as a jamming mitigation. The main idea is >> that allowing full access to liquidity and slots in a channel can result in >> jamming. To prevent this, we allow full access only to neighbours that >> forward HTLC that resolve quickly and generate more profit than the damage >> they can potentially create. >> >> The full suggested jamming mitigation solution includes upfront fees >> together with reputation, see [1] for details. >> >> In the previous episodes: >> >> As presented here [1], we suggest a two part jamming mitigation strategy. >> Reputation-based forwarding is aimed to solve “slow jamming”, where the >> jamming transaction takes a long time to resolve. >> >> The main idea is that each node gives a binary reputation to its >> neighbour. Each channel has a quota of liquidity and slots (say 50% of the >> channel size and 50% of the slots in the channel) dedicated to transactions >> coming from neighbours with reputation 0, or for transactions coming from >> neighbours with reputation 1 that were not endorsed by the neighbour. >> >> For example, when Alice asks Bob to forward to Charlie then: >> >> If (Alice has reputation 1 with Bob) and (Alice endorses transaction): >> >> Forward and endorse >> >> Else: >> >> If (amount < available liquidity quota) and (available slots in quota>0): >> >> Forward HTLC without endorsing >> >> Reduce available liquidity and slots >> >> Else: >> >> Reject >> >> Reputation: >> >> The question we discuss here is how does Alice gain “good” reputation >> (i.e., a score of 1). Alice starts at 0, and she gains and keeps her good >> reputation of 1 by continuously paying more fees to Bob than the damage she >> can inflict. >> >> The 3 main parameters for reputation that each node operator picks are S,L >> and M. Our recommendations are as follows: >> >>- >> >>S should be chosen as the maximum time an HTLC can be unresolved in >>any of Bob’s channels. >>- >> >>M is the revenue generated by Bob’s node in the time S, representing >>the damage Alice could inflict. >>- >> >>L is the time in which Alice should generate M revenue for Bob for >>her to have a good reputation of 1. We suggest L=10S. >> >> >> Alice has reputation 1 if, in the last L seconds, she has forwarded >> payments that generated M satoshi in fees. >> >> As an example: >> >>- >> >>Bob has a maximum CLTV delta of 2 weeks [2] >>- >> >>Over the last 2 weeks, he has earned 0.5 BTC in routing fees >>- >> >>Alice will be considered to have good reputation if she has forwarded >>0.5 BTC of routing revenue to Bob over the last 20 weeks >> >> >> Formally: >> >> Let t be the current time, and let S and
Re: [Lightning-dev] Local Reputation to Mitigate Slow Jamming
Hello, I think the local reputation is more important than upfront fees and should be worked on first because 1) the most likely attack against the network today is the slow jamming attack against which upfront fees are not very effective (an attacker would only consider fast jamming if the network is already resilient to slow jamming) and 2) I think that local reputation may protect well enough against all types of jamming so that we don't even need upfront fees to protect against fast jamming. Regarding the formula itself, I would treat all scores as continuous values between 0 and 1 instead of binary classes. My proposed formula is detailed here: https://docs.google.com/document/d/1hEt1EzyPFJ3gOY7PAvtm_XotTnlQO2r7LSF8Jx34qgc/edit?usp=sharing However my proposal is compatible with Clara's one in that the only thing that needs to be communicated to the peers is how confident we are that the payment will succeed and all the rest is done locally and everyone can use their own formula. I would just prefer this confidence value to be more than one bit but my formula would work with anything, even zero bits. The advantage of using more bits is that we can be more precise in which HTLCs we reject and reduce the number of innocent casualties. Thomas Le jeu. 16 févr. 2023 à 22:29, Clara Shikhelman a écrit : > Hi List, > > We’re writing to seek early feedback on a draft for a neighbour reputation > setting recommendation as a jamming mitigation. The main idea is that > allowing full access to liquidity and slots in a channel can result in > jamming. To prevent this, we allow full access only to neighbours that > forward HTLC that resolve quickly and generate more profit than the damage > they can potentially create. > > The full suggested jamming mitigation solution includes upfront fees > together with reputation, see [1] for details. > > In the previous episodes: > > As presented here [1], we suggest a two part jamming mitigation strategy. > Reputation-based forwarding is aimed to solve “slow jamming”, where the > jamming transaction takes a long time to resolve. > > The main idea is that each node gives a binary reputation to its > neighbour. Each channel has a quota of liquidity and slots (say 50% of the > channel size and 50% of the slots in the channel) dedicated to transactions > coming from neighbours with reputation 0, or for transactions coming from > neighbours with reputation 1 that were not endorsed by the neighbour. > > For example, when Alice asks Bob to forward to Charlie then: > > If (Alice has reputation 1 with Bob) and (Alice endorses transaction): > > Forward and endorse > > Else: > > If (amount < available liquidity quota) and (available slots in quota>0): > > Forward HTLC without endorsing > > Reduce available liquidity and slots > > Else: > > Reject > > Reputation: > > The question we discuss here is how does Alice gain “good” reputation > (i.e., a score of 1). Alice starts at 0, and she gains and keeps her good > reputation of 1 by continuously paying more fees to Bob than the damage she > can inflict. > > The 3 main parameters for reputation that each node operator picks are S,L > and M. Our recommendations are as follows: > >- > >S should be chosen as the maximum time an HTLC can be unresolved in >any of Bob’s channels. >- > >M is the revenue generated by Bob’s node in the time S, representing >the damage Alice could inflict. >- > >L is the time in which Alice should generate M revenue for Bob for her >to have a good reputation of 1. We suggest L=10S. > > > Alice has reputation 1 if, in the last L seconds, she has forwarded > payments that generated M satoshi in fees. > > As an example: > >- > >Bob has a maximum CLTV delta of 2 weeks [2] >- > >Over the last 2 weeks, he has earned 0.5 BTC in routing fees >- > >Alice will be considered to have good reputation if she has forwarded >0.5 BTC of routing revenue to Bob over the last 20 weeks > > > Formally: > > Let t be the current time, and let S and L be constants. > > M is calculated to be the revenue of Bob in time [t-S,t]. The revenue of > Bob is the sum of fees from transactions forwarded by any neighbour besides > Alice + any payments received by Bob. Note that Bob can choose to also take > into account utility gained from sending payments or anything of value to > the node operator. > > Alice has reputation 1 if in the time [t-L,t] she has forwarded HTLCs > that paid M in normalized fees. > > We normalize fees by resolution time to reward payments that resolve > quickly and discount slow resolving payments. Here we assume 10 seconds is > the “normal” resolution time, this number can be bikesheded, and we round > up to avoid penalizing transactions resolved quicker than the “normal”. > > The fee from a single transaction is normalized by the time it took for > the HTLC to resolve, counted in slots of 10 seconds. That is: > > Normalized_fee = (fee)/[ceiling(time_to_resolv
[Lightning-dev] Local Reputation to Mitigate Slow Jamming
Hi List, We’re writing to seek early feedback on a draft for a neighbour reputation setting recommendation as a jamming mitigation. The main idea is that allowing full access to liquidity and slots in a channel can result in jamming. To prevent this, we allow full access only to neighbours that forward HTLC that resolve quickly and generate more profit than the damage they can potentially create. The full suggested jamming mitigation solution includes upfront fees together with reputation, see [1] for details. In the previous episodes: As presented here [1], we suggest a two part jamming mitigation strategy. Reputation-based forwarding is aimed to solve “slow jamming”, where the jamming transaction takes a long time to resolve. The main idea is that each node gives a binary reputation to its neighbour. Each channel has a quota of liquidity and slots (say 50% of the channel size and 50% of the slots in the channel) dedicated to transactions coming from neighbours with reputation 0, or for transactions coming from neighbours with reputation 1 that were not endorsed by the neighbour. For example, when Alice asks Bob to forward to Charlie then: If (Alice has reputation 1 with Bob) and (Alice endorses transaction): Forward and endorse Else: If (amount < available liquidity quota) and (available slots in quota>0): Forward HTLC without endorsing Reduce available liquidity and slots Else: Reject Reputation: The question we discuss here is how does Alice gain “good” reputation (i.e., a score of 1). Alice starts at 0, and she gains and keeps her good reputation of 1 by continuously paying more fees to Bob than the damage she can inflict. The 3 main parameters for reputation that each node operator picks are S,L and M. Our recommendations are as follows: - S should be chosen as the maximum time an HTLC can be unresolved in any of Bob’s channels. - M is the revenue generated by Bob’s node in the time S, representing the damage Alice could inflict. - L is the time in which Alice should generate M revenue for Bob for her to have a good reputation of 1. We suggest L=10S. Alice has reputation 1 if, in the last L seconds, she has forwarded payments that generated M satoshi in fees. As an example: - Bob has a maximum CLTV delta of 2 weeks [2] - Over the last 2 weeks, he has earned 0.5 BTC in routing fees - Alice will be considered to have good reputation if she has forwarded 0.5 BTC of routing revenue to Bob over the last 20 weeks Formally: Let t be the current time, and let S and L be constants. M is calculated to be the revenue of Bob in time [t-S,t]. The revenue of Bob is the sum of fees from transactions forwarded by any neighbour besides Alice + any payments received by Bob. Note that Bob can choose to also take into account utility gained from sending payments or anything of value to the node operator. Alice has reputation 1 if in the time [t-L,t] she has forwarded HTLCs that paid M in normalized fees. We normalize fees by resolution time to reward payments that resolve quickly and discount slow resolving payments. Here we assume 10 seconds is the “normal” resolution time, this number can be bikesheded, and we round up to avoid penalizing transactions resolved quicker than the “normal”. The fee from a single transaction is normalized by the time it took for the HTLC to resolve, counted in slots of 10 seconds. That is: Normalized_fee = (fee)/[ceiling(time_to_resolve/10s)] Some notes 1. The reputation management happens locally, that is, the only protocol change needed is the ability to signal endorsement as a TLV in UpdateAddHTLC. The various parameters can be selected for various risk preferences. 2. We currently suggest a binary reputation for simplicity. Having several buckets could be interesting to study, yet we don’t think that the complexity and the possible privacy issues are worth the potential benefits. 3. For most use cases, having reputation 0 is more than enough. If we send and receive transactions at a low rate, we usually don’t need the full liquidity and slots available in a channel. Reputation mostly comes into play only when a channel is under attack, and then not all transaction are allowed to go through. 4. Following this thread [3]: it is important to note that we are only giving reputation to our direct neighbours. An advantage of this is that we have repeated interactions with them. In practice, this is also the only clean data we have to use when deciding whether to forward an HTLC or not. Best, Carla and Clara [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003740.html [2] https://github.com/lightningnetwork/lnd/blob/de94a4ea5e81799330a72dfde111817b38565d99/htlcswitch/link.go#L51 [3] https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-February/003842.html ___
