Lightning Channels with more than 2 peers? Could 3 ways be better?
549 sats \ 4 comments \ @l0k18 19 Feb 2023 bitcoin
The bar-tab creditcard explanation of Lightning Network is pretty easy to understand for most people, although it gets a little foggy when you start talking about chaining channels to execute a payment.
Basically, in a 2 of 2 multisig, the two nodes update their pending state to a pair of transactions that if broadcast would close the channel and settle the account.
There is actually no reason why channels could not be larger. Based on the tendencies of graphs to go completely factorial, I'm thinking like 3-6 nodes in a "pool". Probably something along similar lines as Bucky Fuller's domes, a mix of 5 and 6 node channels.
The time cost of agreeing on new transactions is based on the number of messages that need to be sent in order to complete the agreement. The "balance" of the channel literally amounts to the "balance point" in between the 5 or 6 nodes. Actually, thinking about it, 3 might be the best arrangement overall, as it has the best ability to tesselate.
One point that is interesting is that 3+ node channels can leak some information relating to their balances that helps guide payment pathfinding. They can advertise which of the group has the lowest balance, and thus should be picked if possible to carry a transaction that moves the multi-channel's balance point closer to the center.
The standard channel transaction processing chatter has a to and fro pattern during which nodes learn about a new payment request, they form their updated versions of the closing transaction, and then are ready for another. The more nodes in a channel, the more messages that are required. It follows the factorial pattern, which is multiplying the numbers involved by each other.
https://en.wikipedia.org/wiki/Factorial
Lightning channels are 2, so settling after each tx requires the tx message plus two settlement messages.
So, settling a transaction on a multi-node channel would be n!+1 messages, and the number of cycles required is n / n!
So there is definitely an upper limit on what is practical, definitely 6 is getting beyond ridiculous at over 100 messages per settlement.
It only takes 3 cycles of 3 nodes sending 2 messages to settle a 3 way, or, on average, about 600ms between any 3 geographic points.
4 nodes need 6 messages, 5 nodes need 24 messages. So, average 200ms travel time we have 1 and 4.5 seconds, or so to settle a transaction (this is a delay, the messages can be concurrently updated).
Due to tesselation, I'm very inclined to suggest that 3 way channels would be better than 2, and would greatly increase connectivity and balance of the network if the triplets were to advertise which node needs sats spent through it.
Not really a "proposal" per se, just got quite into a loop today remembering a "total ordering consensus" idea I had last year that eliminates discretion in mempool transaction selection.
Constructing the LN out of 3 node channels would greatly reduce the total number of channels required, and with advertising the lowest balance channel as part of the protocol, the amount total is not public but which point of the triangle is lowest is, isn't what I'd call doxxing.
The point about tesselation is also important. It would give hints to network participants about how to select who to make a channel with. A node connected to 3 3-way channels doesn't need any more to increase its connectivity.
In the process of pathfinding, you also get more options. Two adjacent strings of triangles interlocking with each other means two parallel paths. Knowing which path is the least full allows the path to be filled and maintain responsivity to new, and maximally large payments.
I'm sure it's gonna happen eventually someone will figure this out. I have seen chatter about coinjoined channels. If all channels had two paths out for every path in, optimal path finding gets a lot easier, and without leaking channel balance, helps the network find balance without doxxing nodes' channel individual balances.
write
preview
related posts
111 sats \ 3 replies \ @Murch 19 Feb 2023
I agree with the sentiment that multiparty channels would be way more efficient for facilitating payments. The challenge with multiparty channels is neither communication overhead, nor privacy because more participants are privy to the payment activity.
In ln-penalty, the currently prevalent update mechanism, you only have two participants. It’s easy to assign blame, because either channel owner can just unilaterally punish the other for publishing an outdated state.
The problem with multiparty channels is in how to curb misbehavior by other channel participants. With three participants, you get an innocent bystander issue: Let’s say Alice, Bob, and Mallory have a channel together. Mallory cheats. Depending on the prior state transitions, she might steal more money from Bob, but Alice might be the first to notice. When Alice broadcasts the penalty, does she get all money in the channel? How does Bob get his share? What if two channel participants are colluding against the third? E.g. Colin colludes with Mallory, Colin holds most of the money, Mallory cheats Alice out of some with an out-of-date commitment transaction, but Colin punishes Mallory and they split the gain.
I wrote more comprehensively about this responding to Why aren't 3 party (or more) channels realistically possible in lightning today?.
We may be able to multiparty channels when we get ln-symmetry (Eltoo), perhaps even Channel Factories.
reply
21 sats \ 2 replies \ @l0k18 OP 19 Feb 2023
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.
reply
21 sats \ 1 reply \ @Murch 19 Feb 2023
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.
  1. All three parties are collaborating
  2. All three participants are unavailable
  3. A single participant becomes temporarily unavailable, the other two want to update the channel
  4. A single participant becomes permanently unavailable
  5. Two participants are unavailable
  6. Two participants are unavailable permanently
  7. A single participant is unavailable, another party tries to cheat
  8. Two participants collude to cheat the third party
  9. Two participants collude to cheat the third party that is currently unavailable
  10. Two participants are temporarily unavailable, the third participant cheats
  11. …
reply
21 sats \ 0 replies \ @l0k18 OP 19 Feb 2023
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