Good morning LL, and list,

> That's a very interesting point. If we were to be able to prevent loop 
> attacks by the sender proving the path is well formed (without revealing who 
> they are or any of the other hops) would this be an alternative solution?
> It seems to me that disabling loop attacks might be much easier than stake 
> certificates.

Loop attacks are not about loops, it only requires that the start and end of a 
payment are controlled by the same entity.

Multiple nodes on the LN may be owned by the same entity.
Nodes, individually as nodes, are trivially cheap and just need 32 bytes of 
entropy from a `/dev/random` near you.
It is the channels themselves, requiring actual funds, high uptime, and not 
being a dick to your counterparty, that are fairly expensive.

Thus, a "loop attack" need not involve a loop per se --- a single entity can 
run any number of nodes with small numbers of channels each, and thereby grief 
the network.

Stake certificates make the node itself expensive, so a single entity running a 
number of nodes cannot perform such loop attacks, since it would require 
entities expensively allocating funds for each node.




On the other hand, if channels are expensive, then a node with channels is 
expensive.

In 
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002890.html
 , which contains the "Z consideration" you were alluding to, I note that the 
"point-to-point property" is already proven by the ***existing*** Lightning 
network without an additional ZK cryptographic proof.

So let me invert that logic and present an even more extreme position:

* There are two griefing attacks:
  * Loop attacks, which are deliberate malicious attacks to lock up funds of 
competitors in order to redirect forwarding towards the attacker.
  * Accidental "attacks", which are accidental due to incompetence, where a 
forwarding node accidentally goes offline and causes payments to be locked up 
for long periods and making everyone on the network cry when HTLCs time out and 
things have to be dropped onchain.
* The point-to-point property, which is already proven by the ***existing*** 
Lightning network, is already sufficient to prevent loop attacks, leaving only 
accidental incompetence-based "attacks".
  * Or: the ***existing*** Lightning Network ***already*** proves the 
point-to-point property presented by t-bast, and that property is ***already*** 
sufficient to prevent the loop attacks.

So, maybe we should instead focus on mitigating the effects of the 
incompetence-based non-attacks [such as this 
proposal](https://github.com/ElementsProject/lightning/issues/2632#issuecomment-736438980),
 instead of attempting to defend against the mirage of loop attacks.


I could be utterly wrong here though.


Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to