Clara Shikhelman [ARCHIVE] on Nostr: 📅 Original date posted:2023-05-31 🗒️ Summary of this message: The HTLC ...
📅 Original date posted:2023-05-31
🗒️ Summary of this message: The HTLC endorsement model introduces a coupling effect between routing scoring algorithms and channel liquidity, with potential issues in compensation and reputation systems.
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230531/adab622d/attachment-0001.html>;
🗒️ Summary of this message: The HTLC endorsement model introduces a coupling effect between routing scoring algorithms and channel liquidity, with potential issues in compensation and reputation systems.
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230531/adab622d/attachment-0001.html>;