📅 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 of 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>;
Clara Shikhelman [ARCHIVE] /
npub1uy…t9vwk
2023-06-19 17:42:26
in reply to nevent1q…4qnx
Author Public Key
npub1uyhgpz5nsfnvdlcqm3erjsdjasd9pdeaejeetwtkvumm6mp3ujlqxt9vwkPublished at
2023-06-19 17:42:26Event JSON
{
"id": "0cf7f2dbb6884258413e7bff8941ba0503fe6a8ba7617e609cb90767f1a13bcb",
"pubkey": "e12e808a938266c6ff00dc723941b2ec1a50b73dccb395b9766737bd6c31e4be",
"created_at": 1687196546,
"kind": 1,
"tags": [
[
"e",
"be5be50dce9786e147a7cb68c485d93fbf586d0f1fb9693bd1921e4d13e50e0b",
"",
"root"
],
[
"e",
"a3eb8ba170cc8cded06ac3c870ee466554689ac3b30d4104ccd9e2837301d71d",
"",
"reply"
],
[
"p",
"6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551"
]
],
"content": "📅 Original date posted:2023-05-31\n🗒️ Summary of this message: The HTLC endorsement model introduces a coupling effect between routing scoring algorithms and channel liquidity, with potential issues of reputation systems.\n📝 Original message:\nHi,\n\n\u003e 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.\n\u003e\n\u003e 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.\n\u003e\n\u003e Bob can also forward but not endorse Alice's HTLC. All of this is a\nfunction of how much credit Bob gives to Alice's judgment. In case of\njamming, the damage that Alice inflicts should be proportional to the\nrevenue she recently created for Bob, and so the more damage, the higher\nthe threshold.\n\n\u003e\n\u003e 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).\n\u003e\n\u003e This system guarantees that if a node was jammed, it was paid a\nsignificant some prior to the attack happening. There is no claim about who\nis paying or the cost of the attack.\n\nI think there is a coupling effec introduced between the historical\nliquidity buckets of routing scoring algorithms and the introduction\nof endorsment scheme with adjustement of the channel liquidity and\nslots in function of local topology reputation.\n\u003e\n\u003e\n\u003e See the LDK scoring engine comments here : https://github.com/lightningdevkit/rust-lightning/blob/eec5ec6b50720144fc23503c3ee9c1c8850517ac/lightning/src/routing/scoring.rs#L336\n\u003e\n\u003e\nThe reading on the channel liquidity can change for different users using\ndifferent routes, but the information a node gets is what liquidity is\navailable for them (and not the state of the channel in general). This\nindeed can fluctuate more than it does now, but so is the liquidity\navailable for a specific node.\n\nBest,\nClara\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230531/adab622d/attachment-0001.html\u003e",
"sig": "e8b0518a3a1bd68d512925fef4ef8cd8aea616d9bc0961fae0b965aad86ea2e8032d4c7095207fa504441a017b373531172775587a2e3ff6cf1e6451f4523f69"
}