Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2023-07-05 🗒️ Summary of this message: The text ...
📅 Original date posted:2023-07-05
🗒️ Summary of this message: The text discusses the potential damage and mitigations in the Lightning Network protocol, including routing fees and on-chain fees. It also explores the difficulty of gaining reputation and suggests a reputation-based mitigation strategy. The author emphasizes the need to consider the adversary's capabilities and information asymmetry. They propose a monetary-based mitigation strategy that quantifies the damage inflicted on the victim.
📝 Original message:
Hi,
> The only damage we can observe in the protocol is routing fees. If we go
ahead with our suggestion, it will be straightforward to choose a different
threshold based on the preference of a node. We have some suggestions for
receiving nodes, for example.
I think there is another obvious damage that we can observe at the
protocol-level, on-chain fees if the target node opens more channel to
compensate the slow-jammed ones, or if there is an automatic force-close in
reason of the low-yield of a channel by the liquidity allocation engine
(e.g something like CLBOSS).
Of course, the "reaction" of a target node is first not very standardized
by a BOLT, second very specific in function of the node activity (pure
routing node, LSP, merchant). So it sounds better deferred to the ulterior
level of development of the mitigations, let's hope we can solve the simple
cases first.
> The difficulty to gain reputation is proportional to the amount of damage
that can be inflicted.
Okay, I think this is where I diverge on the soundness of the HTLC
endorsement solution. For the historical note, when stakes certificates as
a jamming mitigation where proposed back in 2020 [0], the intuition on the
soundness of the security model was it would cost as much for an adversary
to acquire a "fresh" UTXO proof-of-ownership than the level of damage they
can inflict. Which sounds to me the same intuition you're sharing here.
After doing more research the past year [1], it was realized on my side
than the cost function of the adversary is hard to formalize in a world
where the adversary capabilities (quid if the adversary is a miner ?),
source of information (quid if the adversary has better on-chain fees
estimation ?), attacking strategy (quid if they batch a jamming against
multiple target nodes from a _single_ UTXO?) are all unknowns or
"hard-to-guess" variables.
Additionally, the target node source of information is unknown, or at the
very best for the purpose of mitigation design, we can do the assumptions
based on standard/implementation default. However here an adversary is
always free to have a better source of information (the historical
Shannon's quote "The enemy knows the system" in matters of cryptanalysis).
So my own intellectual conclusion is that ideally a reputation-based
mitigation strategy should have a homomorphism with a monetary-based
mitigation strategy in the eventuality of a jamming adversary gaining an
informational asymmetry.
A monetary-based mitigation strategy has the formal advantage that it can
be quantified 100% to the worst-damage inflicted from the preference of the
target node itself.
> "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.
Yes, I think "compensating the victim" is a good direction from the insight
laid out just above. Though note the theoretical caveat on the (probable)
necessity of measuring reputation in pure monetary terms.
> 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
This is why the modern security models and cryptanalysis are based on
assumptions (e.g the DL problem or hardware enforcement of your OS boot).
Such assumptions laying out of mitigations soundness analysis "soft"
criterias. Note such intellectual process has been followed as a standard
design in the redaction of modern Bitcoin standards like BIP340 (schnorr)
and BIP341 (taproot).
For the mathematical note, theorems are not "fully" proved (see the failure
of Hilbert's program to found XXth century mathematics on a complete set of
axioms), though the proving process has a valuable interest to select
theorems for practical applications.
> 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.
Note, modern DDoS attacks mitigations have been discussed using "tokens"
blockchain as a basis for a monetary strategy (e.g the Tor project blog
[0]).
I think all past literature on DDoS attacks has to be reviewed under the
light of a global "ledger" like the Bitcoin blockchain where all the DDoS
attacks can be measured in terms of satoshis, a utility cost function
shared de facto by all the participants of the system.
> Simulation running as we speak.
Formalization of the game-theory of jamming attacks advancing as we speak.
Best,
Antoine
[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002884.html
[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-August/003673.html
[2] https://blog.torproject.org/stop-the-onion-denial/
Le mar. 20 juin 2023 à 22:11, Clara Shikhelman <clara.shikhelman at gmail.com>
a écrit :
> 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/20230705/12627c56/attachment.html>;
🗒️ Summary of this message: The text discusses the potential damage and mitigations in the Lightning Network protocol, including routing fees and on-chain fees. It also explores the difficulty of gaining reputation and suggests a reputation-based mitigation strategy. The author emphasizes the need to consider the adversary's capabilities and information asymmetry. They propose a monetary-based mitigation strategy that quantifies the damage inflicted on the victim.
📝 Original message:
Hi,
> The only damage we can observe in the protocol is routing fees. If we go
ahead with our suggestion, it will be straightforward to choose a different
threshold based on the preference of a node. We have some suggestions for
receiving nodes, for example.
I think there is another obvious damage that we can observe at the
protocol-level, on-chain fees if the target node opens more channel to
compensate the slow-jammed ones, or if there is an automatic force-close in
reason of the low-yield of a channel by the liquidity allocation engine
(e.g something like CLBOSS).
Of course, the "reaction" of a target node is first not very standardized
by a BOLT, second very specific in function of the node activity (pure
routing node, LSP, merchant). So it sounds better deferred to the ulterior
level of development of the mitigations, let's hope we can solve the simple
cases first.
> The difficulty to gain reputation is proportional to the amount of damage
that can be inflicted.
Okay, I think this is where I diverge on the soundness of the HTLC
endorsement solution. For the historical note, when stakes certificates as
a jamming mitigation where proposed back in 2020 [0], the intuition on the
soundness of the security model was it would cost as much for an adversary
to acquire a "fresh" UTXO proof-of-ownership than the level of damage they
can inflict. Which sounds to me the same intuition you're sharing here.
After doing more research the past year [1], it was realized on my side
than the cost function of the adversary is hard to formalize in a world
where the adversary capabilities (quid if the adversary is a miner ?),
source of information (quid if the adversary has better on-chain fees
estimation ?), attacking strategy (quid if they batch a jamming against
multiple target nodes from a _single_ UTXO?) are all unknowns or
"hard-to-guess" variables.
Additionally, the target node source of information is unknown, or at the
very best for the purpose of mitigation design, we can do the assumptions
based on standard/implementation default. However here an adversary is
always free to have a better source of information (the historical
Shannon's quote "The enemy knows the system" in matters of cryptanalysis).
So my own intellectual conclusion is that ideally a reputation-based
mitigation strategy should have a homomorphism with a monetary-based
mitigation strategy in the eventuality of a jamming adversary gaining an
informational asymmetry.
A monetary-based mitigation strategy has the formal advantage that it can
be quantified 100% to the worst-damage inflicted from the preference of the
target node itself.
> "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.
Yes, I think "compensating the victim" is a good direction from the insight
laid out just above. Though note the theoretical caveat on the (probable)
necessity of measuring reputation in pure monetary terms.
> 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
This is why the modern security models and cryptanalysis are based on
assumptions (e.g the DL problem or hardware enforcement of your OS boot).
Such assumptions laying out of mitigations soundness analysis "soft"
criterias. Note such intellectual process has been followed as a standard
design in the redaction of modern Bitcoin standards like BIP340 (schnorr)
and BIP341 (taproot).
For the mathematical note, theorems are not "fully" proved (see the failure
of Hilbert's program to found XXth century mathematics on a complete set of
axioms), though the proving process has a valuable interest to select
theorems for practical applications.
> 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.
Note, modern DDoS attacks mitigations have been discussed using "tokens"
blockchain as a basis for a monetary strategy (e.g the Tor project blog
[0]).
I think all past literature on DDoS attacks has to be reviewed under the
light of a global "ledger" like the Bitcoin blockchain where all the DDoS
attacks can be measured in terms of satoshis, a utility cost function
shared de facto by all the participants of the system.
> Simulation running as we speak.
Formalization of the game-theory of jamming attacks advancing as we speak.
Best,
Antoine
[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002884.html
[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-August/003673.html
[2] https://blog.torproject.org/stop-the-onion-denial/
Le mar. 20 juin 2023 à 22:11, Clara Shikhelman <clara.shikhelman at gmail.com>
a écrit :
> 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/20230705/12627c56/attachment.html>;