Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2023-06-18 🗒️ Summary of this message: The proposed ...
📅 Original date posted:2023-06-18
🗒️ Summary of this message: The proposed HTLC endorsement system for mitigating jamming attacks in Lightning Network lacks clarity on how fees compensate for damage inflicted. A formal definition of the problem and rigorous analysis is needed before deploying any half-baked solutions.
📝 Original message:
Hi,
> 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 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.
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 ? 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 ?
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 ?
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.
I'm not pretending to have done the "cryptoeconomics-analysis" work for the
solution I'm proposing (staking credentials) or something like circuit
breaker. I just would like to underscore we should be quite cautious in
deploying half-baked mitigations, that might provoke more harm than relief
to routing node operators. Sorry not sorry if it's interpreted as a rant,
we have already enough broken stuff in Lightning...
> 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.
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 ?
Again on this last point, I would say intuitively any other proposed
jamming solution would come with downsides on the routing traffic succes,
though hard to say the trade-offs.
Best,
Antoine
Le mer. 31 mai 2023 à 21:21, Clara Shikhelman <clara.shikhelman at gmail.com>
a écrit :
> 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/20230619/c72c2452/attachment.html>;
🗒️ Summary of this message: The proposed HTLC endorsement system for mitigating jamming attacks in Lightning Network lacks clarity on how fees compensate for damage inflicted. A formal definition of the problem and rigorous analysis is needed before deploying any half-baked solutions.
📝 Original message:
Hi,
> 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 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.
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 ? 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 ?
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 ?
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.
I'm not pretending to have done the "cryptoeconomics-analysis" work for the
solution I'm proposing (staking credentials) or something like circuit
breaker. I just would like to underscore we should be quite cautious in
deploying half-baked mitigations, that might provoke more harm than relief
to routing node operators. Sorry not sorry if it's interpreted as a rant,
we have already enough broken stuff in Lightning...
> 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.
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 ?
Again on this last point, I would say intuitively any other proposed
jamming solution would come with downsides on the routing traffic succes,
though hard to say the trade-offs.
Best,
Antoine
Le mer. 31 mai 2023 à 21:21, Clara Shikhelman <clara.shikhelman at gmail.com>
a écrit :
> 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/20230619/c72c2452/attachment.html>;