Why aren't 3 party (or more) channels realistically possible in lightning today?

Question

Speaking with Ben on twitter it appears that it isn't feasible without eltoo to create more than 2 party channels on the lightning network today. Why exactly is that the case today and how does eltoo solve it?

Answer 1

Today's lightning channels use the ln-penalty update mechanism. Each time an HTLC is staged or resolved, the channel owners negotiate new commitment transactions for each side. As part of the negotiation, channel owners must renounce the old state: after acquiring the new state, each provides the counterparty a breach remedy keyed to the prior state. This breach remedy allows a channel owner to publish a justice transaction to claim all funds in the channel should the other party broadcast the outdated state. Ln-penalty requires that each party has a distinct commitment transaction for each state since the funds on the publisher's side are locked for some time to give the defender a chance to use the breach remedy.

Each party must keep all prior breach remedies and outdated backups become toxic waste. If a node accidentally publishes an old state, they forfeit all funds in the channel.

I do not see how the penalty mechanism could work with more parties. Let's assume we had a channel opened by Alice, Bob, and Mallory. Mallory opened the channel with 0.6 ₿. At a later stage, Alice has 0.4 ₿, Bob has 0.15 ₿, and Mallory only holds 0.05 ₿. Mallory tries to unilaterally close the channel with the initial state to reclaim all 0.6 ₿. The breach remedies Alice and Bob hold were created when Mallory renounced the initial state. Does whoever broadcast it get all the money? That would mean that Alice or Bob is punished for Mallory's transgression. Is the money split in half? That way two channel owners could steal from a third whenever one party's channel capacity exceeds half the channel balance. Perhaps a justice transaction could pay out into the shared custody of Alice and Bob, but even then, how would Alice and Bob ensure that each get at least the amount that they could lay claim to in the last state?

I posit that designing an ln-penaly-like update mechanism that guarantees fair outcomes in all possible scenarios for three or more parties would be vastly more complicated and probably have significantly more roundtrips and overhead. I suspect that it might require renegotiating all prior breach remedies for each state update. (Happy to be convinced otherwise, if you have a nifty construction in mind, though. ;))

The Decker-Russell-Osuntokun update mechanism (“Eltoo”) manages to ratchet the channel state forward without asymmetry. Instead of having a separate commitment transaction for each party, a symmetric Update Transaction is created for each new channel state shared by all parties. Update Transactions tie only to the scriptPubKey and amount of a prior transaction output instead of a specific outpoint (which requires SIGHASH_ANYPREVOUT). Each Update Transaction spends the output of the Setup Transaction or any Update Transaction older than itself. All Update Transactions share the same input amount and pay the same output amount to the same scriptPubKey. The payout to the channel owners happens only in a later Settlement Transaction which can only be used after the corresponding Update Transaction has a number of confirmations (via OP_CHECKSEQUENCEVERIFY). This gives other channel owners time to submit any newer Update Transactions if an outdated Update Transaction was published.

^{via eltoo: A Simple Layer2 Protocol for Bitcoin}

There is no punishment for the publication of an outdated state. However, the Update Transactions itself do not pay any fees since input amount and output amount are the same. The publisher must add another input to provide fees (and possibly another output to reclaim change). However, while an older Update Transaction is in the mempool or even after it has already been included in a block, newer Update Transactions can be submitted to enforce a more beneficial outcome for other channel owners (or to skip directly to the newest Update transaction). An unsuccessful attacker wastes the transaction cost of broadcasting an outdated state when their transaction confirms but is later superseded.

Since the channel state is symmetric and there is no state specific breach remedy, each (honest) channel owner needs only the latest state which reduces the amount of state channel owners need to keep track off. Old channel backups are no longer toxic waste that immediately trigger loss of all funds. In case of an actual data loss, other channel owner can ratchet forward to any later state (which may still lose the negligent channel owner some or all funds, or may be the latest state in the case of an honest counterparty). Since the channels are symmetric, the overhead of having multiparty channels is linear. It may still be impractical to create channels with numerous channel owners, since each channel owner must sign every Update Transaction, but a handful channel owners should be feasible. The overhead for updating the channel state may also be somewhat mitigated via Channel Factories which allow subsets of the channel owners to have segregated balances they can update among themselves.