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.
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.
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.ln-symmetry (Eltoo), perhaps even Channel Factories.