21 sats \ 2 replies \ @l0k18 OP 19 Feb 2023 \ parent \ on: Lightning Channels with more than 2 peers? Could 3 ways be better? bitcoin
Let's say Alice, Bob and Charlie open a channel together.
Scenario A:
Bob and Charlie are colluding, and trigger an early close and Alice loses a few, average 50% channel opening size, from this mischief.
Scenario B:
Only Charlie is cheating. Alice and Bob get alerted by their watchtowers and they price Charlie out of his ill-begotten early close in his favour.
Psychologically, A is more scary than B. It is also the scenario you focus on. But, if you take your baseline assumptions, ie, 50% chance rando newbie is a cheat, which is pretty pessimistic, you at least mitigate your cost by standing strong with your 3 way non-evil partner by easily at least 50% of potential loss. If both your guys cheat you, you can still deny them of almost all of their profits if you're alert and ready to bid them out of the mempool.
I'm not sure if 3 or 4 is the better geometry, 3 is just sorta native to humans because we live on a sphere. But the point is that N points need two connections each to potentially form a single circle. They can cover a 2D surface (or sphere) with 3 connections each, and then we can get into 4 dimensions with 4 connections per node. This is akin to teleporting or wormholing.
But I'm pretty sure that tesselating triangle or tetrahedral geometries are optimal for path finding and if establishing paths is a lot more expensive than the profit of operating them, then you don't want to waste your time with suboptimal numbers.
If you based the LN network topology heuristic on these principles, then you would have a lot less problems with balancing channels, and out of 3, it is only 1 bit of information leaked to say "channel C of A, B and C is the lowest" and use an appropriate proportional/integral error correction to prevent alias distortion to prevent telling flip-flops of this balance state from oscillating and leaking more information.
I think your policies make sense for randos but not for friends or associates. I think that in the typical situation, where the minority is criminal, 3 and 4 node channels topology is far more efficient.
The Lightning Network currently guarantees that any conflict can be resolved fairly or to the detriment of a cheating party. You introduce the new assumption that channel participants trust their counterparties. If we trust each other, we may as well use a custodial solution or shared ownership of a single Lightning Node—you don’t need a multiparty channel at all.
If you however wish to solve the conundrum of multiparty channels with the same security assumptions as used by the Lightning Network today, you need a cryptographic protocol that guarantees a fair outcome in all cases, e.g.
- All three parties are collaborating
- All three participants are unavailable
- A single participant becomes temporarily unavailable, the other two want to update the channel
- A single participant becomes permanently unavailable
- Two participants are unavailable
- Two participants are unavailable permanently
- A single participant is unavailable, another party tries to cheat
- Two participants collude to cheat the third party
- Two participants collude to cheat the third party that is currently unavailable
- Two participants are temporarily unavailable, the third participant cheats
- …
reply
yeah, the whole thing about how LN runs "hot" is problematic. Sometimes stuff gets out of sync. I'm sure there is many more things, the 3 node channels idea was just about improving path efficiency and chain transaction costs.
It reminds me of a whole stream of ideas I've been cooking up over the years related to precisely providing adequate experience without more or less signing a contract with the devil in the blood of your firstborn.
Nostr, for example, is a distributed generic event log. It could do things especially for async issues like about half the issues you name above.
I just got done building two neat little cryptographic protocols for source routed onion relay network. The more I dig into this stuff the more I realise how broad the horizon actually is.
Also, on my subject of post: I don't think the guarantees of 2 party 2 of 2 multisig based channels is any different from 3 of 3 in any real, material way, while cutting 1/3 of your message cost over the whole network and enabling shallow transparency of channel balances.
What does someone do if it is necessary for them to close a channel? Or if they simply can't run their server for a day here and there. LN doesn't really prescribe punishments for absentees. Payments fail, counterparty gets antsy about logs full of failed payment probes and attempts.
Almost all bad scenarios with LN involve active, not passive attacks. Humans are lazy. Half of them are even lazier than that. Fat fingers close channels accidentally. Sometimes misunderstood configuration options too.
More work needs to be done on the cryptographic/game theory protocols to advance things. I'm pretty handy at this kind of thought process, and just got done with two small pieces that are central to Indra. I'm staring at my IDE wishing I could get back to solving cryptographic protocol problems and not boring crap like implementing empty, mostly boilerplace APIs, managing configuration, persisting state.
reply