<p>Today's lightning channels use the <em>ln-penalty</em> 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 <em>breach remedy</em> 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.</p>
<p>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.</p>
<p>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?</p>
<p>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. ;))</p>
<p>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 <em>Update Transaction</em> is created for each new channel state shared by all parties. Update Transactions tie only to the <code>scriptPubKey</code> and amount of a prior transaction output instead of a specific outpoint (which requires <a href="http://anyprevout.xyz/" rel="nofollow noreferrer"><code>SIGHASH_ANYPREVOUT</code></a>). Each Update Transaction spends the output of the <em>Setup Transaction</em> or any Update Transaction older than itself. All Update Transactions share the same input amount and pay the same output amount to the same <code>scriptPubKey</code>. The payout to the channel owners happens only in a later <em>Settlement Transaction</em> which can only be used after the corresponding Update Transaction has a number of confirmations (via <code>OP_CHECKSEQUENCEVERIFY</code>). This gives other channel owners time to submit any newer Update Transactions if an outdated Update Transaction was published.</p>
<p><a href="https://i.sstatic.net/PA2NN.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/PA2NN.png" alt="A UML diagram showing the state transitions in an Eltoo channel. The initial state is followed by a Setup Transaction. The Setup Transaction either can be spent by Update Transaction 1 (or higher), or Settlement Transaction 0. Update Transaction 1 in turn can be spent by Update Transaction 2 (or higher) or Settlement Transaction 1." /></a><br />
<sup>via <a href="https://blockstream.com/eltoo.pdf" rel="nofollow noreferrer">eltoo: A Simple Layer2 Protocol for Bitcoin</a></sup></p>
<p>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.</p>
<p>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 <a href="https://bitcoin.stackexchange.com/a/67187/5406"><em>Channel Factories</em></a> which allow subsets of the channel owners to have segregated balances they can update among themselves.</p>

CC BY-SA 4.0
2023-06-11T22:41:36.507Z
Nice explanation, thx, I was wondering on what prevents generalization of a 2-of-2 lightning channel to 3 (or more) parties.
OptOut
CC BY-SA 4.0
2023-06-11T22:44:13.250Z
I wonder if choosing a 'channel master' in the hypothetical 3 (or 3+) party lightning channel generalization, and restricting transactions to/from channel master only (in practice the LSP) would reduce the set of possible combinations to a manageable level?
OptOut
CC BY-SA 4.0
2022-12-06T00:34:02.037Z
2022-12-06T16:35:35.343Z
2022-12-06T16:35:35.343Z
Murch
<p>Speaking with <a href="https://twitter.com/benthecarman/status/1599863436703588352" rel="noreferrer">Ben on twitter</a> 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?</p>

CC BY-SA 4.0
2022-12-05T23:37:20.817Z
AJ answered this on Twitter if someone wants to add an answer https://twitter.com/ajtowns/status/1599892685095329792?s=20&t=U4AZm3ZGpz4s6k1sMudimA
Michael Folkson
<lightning-network><eltoo>
Why aren't 3 party (or more) channels realistically possible in lightning today?
arshbot
# Why aren't 3 party (or more) channels realistically possible in lightning today?

(Asked by: username_0 on 2022-12-05)

Speaking with [Ben on twitter](https://twitter.com/benthecarman/status/1599863436703588352) 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?

**Tags:** lightning-network, eltoo

> **Comments:**
> **username_1**: AJ answered this on Twitter if someone wants to add an answer https://twitter.com/ajtowns/status/1599892685095329792?s=20&t=U4AZm3ZGpz4s6k1sMudimA  

---

## 1 answers

### Answer by username_2 on 2022-12-06. Score: 8 | Accepted answer

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`](http://anyprevout.xyz/)). 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.

[![A UML diagram showing the state transitions in an Eltoo channel. The initial state is followed by a Setup Transaction. The Setup Transaction either can be spent by Update Transaction 1 (or higher), or Settlement Transaction 0. Update Transaction 1 in turn can be spent by Update Transaction 2 (or higher) or Settlement Transaction 1.](https://i.sstatic.net/PA2NN.png)](https://i.sstatic.net/PA2NN.png)  
via [eltoo: A Simple Layer2 Protocol for Bitcoin](https://blockstream.com/eltoo.pdf)

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*](https://bitcoin.stackexchange.com/a/67187/5406) which allow subsets of the channel owners to have segregated balances they can update among themselves.

> **Comments:**
> **username_3**: Nice explanation, thx, I was wondering on what prevents generalization of a 2-of-2 lightning channel to 3 (or more) parties.  
> **username_3**: I wonder if choosing a 'channel master' in the hypothetical 3 (or 3+) party lightning channel generalization, and restricting transactions to/from channel master only (in practice the LSP) would reduce the set of possible combinations to a manageable level?  

---

