Hello Zeeman, If I understand well the "point-to-point property" is the following : you can authenticate an incoming HTLC traffic from your neighbors owing to their expensive channels.
My concern with this approach relies on the fact that a routing node isn't decisionary of the HTLC traffic going through itself. Thus its outgoing traffic might be far superior to its locked channel utxos and it will have to compensate HTLC receiver for the difference. You're back to some fees mechanism for everyone to do its account. The interesting property with stake certificates is to overlay the liquidity effective user with the HTLC sender. This last one should care about using liquidity resources reasonably, not the routing nodes. IMO, the more interesting point you're underscoring is that we shouldn't bind a HTLC traffic volume to a channel size. E.g you have a small channel but a high HTLC traffic spread through the day and that's lawful. What we may consider is a stake certificate/point-to-point control only relying on utxo uniqueness, and not the amount locked. If a utxo-authenticated HTLC-traffic is far beyond the median, just blacklist the utxo, thus forcing a utxo spend (and bearing onchain fees) by any liquidity abuser. Cheers, Antoine Le mar. 1 déc. 2020 à 07:11, ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> a écrit : > 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 >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
