ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2020-12-01 📝 Original message: Good morning LL, and ...

📅 Original date posted:2020-12-01
📝 Original message:
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