📅 Original date posted:2020-12-01
📝 Original message:
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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201201/e432323a/attachment-0001.html>;
Antoine Riard [ARCHIVE] /
npub1vj…4x8dd
2023-06-09 13:01:38
in reply to nevent1q…tqdr
Author Public Key
npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8ddPublished at
2023-06-09 13:01:38Event JSON
{
"id": "9a48ea000034e2d96388656c2ac4ad98e83577d327f0ad25a9127be73a604413",
"pubkey": "6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551",
"created_at": 1686315698,
"kind": 1,
"tags": [
[
"e",
"cf62c1c9ba62fff4a5cf755628bee75840429fbdff26c4293acc0bc18dd74e69",
"",
"root"
],
[
"e",
"282eaf65f233b3aaf2e5fe935d1dd6576aaf1f92e0e8442d013210c45154cc14",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2020-12-01\n📝 Original message:\nHello Zeeman,\n\nIf I understand well the \"point-to-point property\" is the following : you\ncan authenticate an incoming HTLC traffic from your neighbors owing to\ntheir expensive channels.\n\nMy concern with this approach relies on the fact that a routing node isn't\ndecisionary of the HTLC traffic going through itself. Thus its outgoing\ntraffic might be far superior to its locked channel utxos and it will have\nto compensate HTLC receiver for the difference. You're back to some fees\nmechanism for everyone to do its account.\n\nThe interesting property with stake certificates is to overlay the\nliquidity effective user with the HTLC sender. This last one should care\nabout using liquidity resources reasonably, not the routing nodes.\n\nIMO, the more interesting point you're underscoring is that we shouldn't\nbind a HTLC traffic volume to a channel size. E.g you have a small channel\nbut a high HTLC traffic spread through the day and that's lawful. What we\nmay consider is a stake certificate/point-to-point control only relying on\nutxo uniqueness, and not the amount locked. If a utxo-authenticated\nHTLC-traffic is far beyond the median, just blacklist the utxo, thus\nforcing a utxo spend (and bearing onchain fees) by any liquidity abuser.\n\nCheers,\n\nAntoine\n\nLe mar. 1 déc. 2020 à 07:11, ZmnSCPxj via Lightning-dev \u003c\nlightning-dev at lists.linuxfoundation.org\u003e a écrit :\n\n\u003e Good morning LL, and list,\n\u003e\n\u003e\n\u003e \u003e That's a very interesting point. If we were to be able to prevent loop\n\u003e attacks by the sender proving the path is well formed (without revealing\n\u003e who they are or any of the other hops) would this be an alternative\n\u003e solution?\n\u003e \u003e It seems to me that disabling loop attacks might be much easier than\n\u003e stake certificates.\n\u003e\n\u003e Loop attacks are not about loops, it only requires that the start and end\n\u003e of a payment are controlled by the same entity.\n\u003e\n\u003e Multiple nodes on the LN may be owned by the same entity.\n\u003e Nodes, individually as nodes, are trivially cheap and just need 32 bytes\n\u003e of entropy from a `/dev/random` near you.\n\u003e It is the channels themselves, requiring actual funds, high uptime, and\n\u003e not being a dick to your counterparty, that are fairly expensive.\n\u003e\n\u003e Thus, a \"loop attack\" need not involve a loop per se --- a single entity\n\u003e can run any number of nodes with small numbers of channels each, and\n\u003e thereby grief the network.\n\u003e\n\u003e Stake certificates make the node itself expensive, so a single entity\n\u003e running a number of nodes cannot perform such loop attacks, since it would\n\u003e require entities expensively allocating funds for each node.\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e On the other hand, if channels are expensive, then a node with channels is\n\u003e expensive.\n\u003e\n\u003e In\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002890.html\n\u003e , which contains the \"Z consideration\" you were alluding to, I note that\n\u003e the \"point-to-point property\" is already proven by the ***existing***\n\u003e Lightning network without an additional ZK cryptographic proof.\n\u003e\n\u003e So let me invert that logic and present an even more extreme position:\n\u003e\n\u003e * There are two griefing attacks:\n\u003e * Loop attacks, which are deliberate malicious attacks to lock up funds\n\u003e of competitors in order to redirect forwarding towards the attacker.\n\u003e * Accidental \"attacks\", which are accidental due to incompetence, where\n\u003e a forwarding node accidentally goes offline and causes payments to be\n\u003e locked up for long periods and making everyone on the network cry when\n\u003e HTLCs time out and things have to be dropped onchain.\n\u003e * The point-to-point property, which is already proven by the\n\u003e ***existing*** Lightning network, is already sufficient to prevent loop\n\u003e attacks, leaving only accidental incompetence-based \"attacks\".\n\u003e * Or: the ***existing*** Lightning Network ***already*** proves the\n\u003e point-to-point property presented by t-bast, and that property is\n\u003e ***already*** sufficient to prevent the loop attacks.\n\u003e\n\u003e So, maybe we should instead focus on mitigating the effects of the\n\u003e incompetence-based non-attacks [such as this proposal](\n\u003e https://github.com/ElementsProject/lightning/issues/2632#issuecomment-736438980),\n\u003e instead of attempting to defend against the mirage of loop attacks.\n\u003e\n\u003e\n\u003e I could be utterly wrong here though.\n\u003e\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201201/e432323a/attachment-0001.html\u003e",
"sig": "02844089a5439640469ff1e690bbad43eeac25a4eeb174eaf14abebb6db687161beb86cd17551b555fa3422c597de4d53cecf03a15ad3f0eff8ad664dd5c632e"
}