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 <clara.shikhel...@gmail.com> 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 <thomas.h...@acinq.fr> 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 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 >>> _______________________________________________ >>> 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
