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 <clara.shikhel...@gmail.com> 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 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
