Clara Shikhelman [ARCHIVE] on Nostr: 📅 Original date posted:2023-06-20 🗒️ Summary of this message: The proposed ...
📅 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>;
🗒️ 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>;