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
