📅 Original date posted:2023-06-20
🗒️ Summary of this message: The proposed htlc endorsement system aims to compensate victims of jamming attacks, but the criteria for evaluation and compensation are unclear. The effectiveness of any solution needs to be rigorously analyzed.
📝 Original message:
Hi,
> 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 ?
>
The only damage we can observe in the protocol is routing fees. If we go
ahead with our suggestion, it will straightforward to choose a different
threshold based on the preference of a node. We have some suggestions for
receiving nodes, for example.
> 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 ?
>
The difficulty to gain reputation is proportional to the amount of damage
that can be inflicted.
>
> 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 ?
>
"A significant cost", unlike right now where it's practically free.
Because we don't know how deep are the pockets of the attacker, our focus
is on compensating the victim.
> 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.
>
Because a lot of the criteria are "soft" (UX, ease of implementation), we
cannot prove theorems. We are working on further simulations for the
quantifiable criteria, to see if theory meets practice.
Note that DDoS attacks are notoriously difficult to mitigate (see [0], for
example), so we are trying to do our best in the context of lightning using
the available tools.
> 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 ?
>
Simulation running as we speak.
Best,
Clara
[0]
https://www.sciencedirect.com/science/article/abs/pii/S1389128603004250?casa_token=BauKTUZ1yEYAAAAA:Ny9OvPXunkvLZgJD1bYQ_amV-rsMVRbYKozWchYB9ZpFZ3dNFfJnK74UYl7di9R24aDhrw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230620/ece0d563/attachment.html>;
Clara Shikhelman [ARCHIVE] /
npub1uy…t9vwk
2023-06-21 08:28:11
in reply to nevent1q…va5u
Author Public Key
npub1uyhgpz5nsfnvdlcqm3erjsdjasd9pdeaejeetwtkvumm6mp3ujlqxt9vwkPublished at
2023-06-21 08:28:11Event JSON
{
"id": "a40cf61defbfebd791edd4e38384c297269ebe46c8ed178e749df936d803aa85",
"pubkey": "e12e808a938266c6ff00dc723941b2ec1a50b73dccb395b9766737bd6c31e4be",
"created_at": 1687336091,
"kind": 1,
"tags": [
[
"e",
"29c2037ca6ae6ddd728490383c7643edaf49a9572f1b45c5089ac735277cdff9",
"",
"root"
],
[
"e",
"037f63549516f47acf3bd80eab54a954d14bcbc69e704d8e58c52ce6b977bbb9",
"",
"reply"
],
[
"p",
"6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551"
]
],
"content": "📅 Original date posted:2023-06-20\n🗒️ Summary of this message: The proposed htlc endorsement system aims to compensate victims of jamming attacks, but the criteria for evaluation and compensation are unclear. The effectiveness of any solution needs to be rigorously analyzed.\n📝 Original message:\nHi,\n\n\n\u003e Sure, I understand that in case of an attack, a routing node should have\n\u003e been paid a significant fee sum by the peer originating the jamming\n\u003e traffic. However from my understanding this is unclear with the proposed\n\u003e htlc endorsement system than the fees paid are fully economically\n\u003e compensating the damage inflicted to the victim ?\n\u003e\n\nThe only damage we can observe in the protocol is routing fees. If we go\nahead with our suggestion, it will straightforward to choose a different\nthreshold based on the preference of a node. We have some suggestions for\nreceiving nodes, for example.\n\n\n\u003e Or if it's a proportional compensation, and if proportional the ratio\n\u003e between the fees and the reputation is static or dynamic, and if dynamic\n\u003e which are the criterias of evaluation ?\n\u003e\n\nThe difficulty to gain reputation is proportional to the amount of damage\nthat can be inflicted.\n\n\n\u003e\n\u003e Note, outlawing the cost of the attack from the system guarantees sounds\n\u003e contrary to the htlc endorsement design goal shown in your gist: \"the goal\n\u003e of this proposal is to produce a mitigation that has...a significant cost\n\u003e to persistent attackers\", or are the design goals proposed elsewhere ?\n\u003e\n\n \"A significant cost\", unlike right now where it's practically free.\nBecause we don't know how deep are the pockets of the attacker, our focus\nis on compensating the victim.\n\n\n\u003e So I still don't know the precise problem to be solved by any jamming\n\u003e mitigation, in a formal fashion, nor the correctness conditions required of\n\u003e a solution. As far as I can tell, such information is not present in the\n\u003e \"unjamming lightning\" paper (while the paper claims to \"systematically\n\u003e analyze the solution space\" it does not formalize the problem, at least in\n\u003e terms of abstract definition that holds independently of the solution\n\u003e adopted).\n\u003e\nI think there is still an undervaluation of how much the liquidity griefing\n\u003e issues affecting Lightning and second-layers, of which jamming is only one,\n\u003e is novel from the viewpoint of financial cryptography/computer security\n\u003e literature. At the best, I think we should aim to evaluate the\n\u003e effectiveness of any jamming solution with the same conceptual rigor as\n\u003e modern cryptanalysis (understood notions like shannon cipher, perfect\n\u003e security, switching lemma).\n\u003e\nWithout such rigor of analysis, I don't think we'll be able to give\n\u003e \"measurable\" bounds to any solution, and know when there is a wreckage\n\u003e because we're modifying some subtle parameters like channel opening\n\u003e default, or the adversaries can access superior sources of information to\n\u003e decide when to launch a jamming attack where the sum paid does _not_ cover\n\u003e the operational cost of a routing hop.\n\u003e\n\nBecause a lot of the criteria are \"soft\" (UX, ease of implementation), we\ncannot prove theorems. We are working on further simulations for the\nquantifiable criteria, to see if theory meets practice.\nNote that DDoS attacks are notoriously difficult to mitigate (see [0], for\nexample), so we are trying to do our best in the context of lightning using\nthe available tools.\n\n\n\u003e So if you recognize that htlc endorsement can fluctuate the link-level\n\u003e liquidity more than it does now, at the very least it would be good to come\n\u003e with simulations on how it might downgrade HTLC routing traffic ?\n\u003e\n\nSimulation running as we speak.\n\nBest,\nClara\n\n[0]\nhttps://www.sciencedirect.com/science/article/abs/pii/S1389128603004250?casa_token=BauKTUZ1yEYAAAAA:Ny9OvPXunkvLZgJD1bYQ_amV-rsMVRbYKozWchYB9ZpFZ3dNFfJnK74UYl7di9R24aDhrw\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230620/ece0d563/attachment.html\u003e",
"sig": "3de5b25cff2fcac1208fe92e1019087d5a51105bae07bc6f05976c1bec9cceb25af66473e511d8328c3112535d285eb92e398afbcdc813e7557bf50d61aa8c02"
}