<p>When two channel participants open a channel or update it, they exchange commitment transactions. These commitment transactions allow each party to unilaterally close the channel.</p>
<p>The commitment transactions are asymmetric in that they lock the closing party's funds when broadcast, i.e. Alice's commitment transaction locks Alice's funds, Bob's commitment transaction locks Bob's funds. The counterparty's funds are immediately available for spending. The lock on the closing party's funds (the &quot;breach remedy&quot;) gives the counterparty time to impound the closing party's funds via a &quot;punishment transaction&quot; if an outdated state was broadcast.</p>
<p><a href="https://i.sstatic.net/TsLHb.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/TsLHb.png" alt="Illustration of the asymmetric commitment transaction" /></a></p>
<p><sup><em><strong>Commitment Transaction</strong> (via <a href="https://www.ellemouton.com/blog/view/4" rel="nofollow noreferrer">Elle Mouton</a>): Alice's output to herself (<code>to_local</code>) in her commitment transaction is encumbered with a Revocable Sequence Maturity Contract (RSMC) which allows her to revoke the commitment transaction later, while the output to Bob (<code>to_remote</code>) is a simple send, vice versa for Bob's transaction.</em></sup></p>
<p>When a payment is made in the channel and the channel is updated with new commitment transactions, the outdated channel state is revoked by revealing the secrets to spend the old commitment transactions (d<sub>B1</sub> and d<sub>A1</sub> in the graphic). This makes the old state &quot;toxic&quot; in the sense that (accidentally) using the outdated commitment transaction to close the channel will cost the closer all their funds in the channel.</p>
<p>Updating a channel to make a payment in the punishment-based channel setup requires a procedure with multiple roundtrips in a specific order to ensure that there is no disadvantageous intermittent state for either party. If it were possible to map this onto a multiparty setup, it would be extremely complex.</p>
<p>In Eltoo, commitment transactions are shared across the participants. Broadcasting an outdated state is corrected by overwriting it with the latest state. Since the channel state is symmetric, it is trivial to have channels with more than two parties. This could take e.g. the form of four parties creating a four-of-four multisig output to anchor a channel. Each party would have a balance in the channel which they could use to send funds to another channel participant, or other network participants. With Schnorr signatures and key aggregation, such channels would be extremely efficient as they could still fit in the size of a singlesig output. Practically, the number of participants would still be limited as any channel update would have to be agreed upon by every participant, and any one participant wanting to close the channel would close it for all. Possibly, this could be used as a liquidity pool or for <a href="https://bitcoin.stackexchange.com/q/67158/5406">channel factories</a> among large players that can guarantee continuous availability.</p>

CC BY-SA 4.0
2019-01-02T16:39:46.917Z
Thank you. Just when you say we can have channels with more than two parties, do you mean that we can have a bidirectional payment channel between e.g. 4 participants (payer/recipient) like this figure? ( https://imgur.com/5KVLP6G ) Or do you mean something else? And does `eltoo` such a capability? Thanks
Questioner
CC BY-SA 4.0
2019-01-02T18:06:10.623Z
with the current lightning network multiparty channels are theoretically possible but not implemented. in eltoo these channels are much easier to implement because all parties share the same state and update / settlement transactions. Therefor if we switch to eltoo channels one day we will most likely get multiparty channels implemented
Rene Pickhardt
CC BY-SA 4.0
2019-01-02T19:25:08.007Z
And in that case (having multiparty channels), we can establish a large channel between participants, such that they do not need to do **multi hop** payments since a direct link exists between them and therefore we do not need to do a **routing** process, isn't it? Do you agree? Thank you.
Questioner
CC BY-SA 4.0
2019-01-03T06:52:28.920Z
I've amended my answer to give more details on some potential applications for Eltoo.
Murch
CC BY-SA 4.0
2019-01-02T15:51:19.330Z
2021-03-24T16:16:16.600Z
2021-03-24T16:16:16.600Z
Murch
<p>In following paper, written by Christian Decker et al., there is a paragraph that is not clear to me.  </p>

<p><a href="https://blockstream.com/eltoo.pdf" rel="nofollow noreferrer">eltoo: A Simple Layer2 Protocol for Bitcoin</a></p>

<blockquote>
  <p>"The central idea of Lightning is to invalidate an old state by
  punishing the participant publishing it, and claiming all the funds in
  the channel. This however introduces an intrinsic <strong>asymmetry</strong> in the
  information <strong>tracked by each participant</strong>. The replaced states <strong>turn into
  toxic information</strong> as soon as they are replaced, and leaking that
  information may result in funds being stolen. The asymmetry also
  <strong>limits Lightning to two participants</strong>."</p>
</blockquote>

<p>There are following points that are not clear to me:</p>

<p><strong>(1)</strong> Does <strong>asymmetry</strong> mean the information tracked by each participant (payer and recipient) <strong>are NOT the same (or are NOT equal)</strong>?</p>

<p><strong>(2)</strong> What is the <strong>reason</strong> of this asymmetry?</p>

<p><strong>(3)</strong> What does "<em>turn into <strong>toxic</strong> information</em>" mean?</p>

<p><strong>(4)</strong> The last sentence: "<em>asymmetry also limits Lightning to <strong>two participants</em></strong>", Does it mean that we can expect a payment transaction can have more than two participants? since a payment logically has only two participants: a payer and a recipient.   </p>

<security><lightning-network><terminology><ln-commitment-transaction><eltoo>
Lightning Network: asymmetry in the information tracked by each participant?
Questioner
# Lightning Network: asymmetry in the information tracked by each participant?

(Asked by: username_0 on 2019-01-02)

In following paper, written by Christian Decker et al., there is a paragraph that is not clear to me.

[eltoo: A Simple Layer2 Protocol for Bitcoin](https://blockstream.com/eltoo.pdf)

> "The central idea of Lightning is to invalidate an old state by
> punishing the participant publishing it, and claiming all the funds in
> the channel. This however introduces an intrinsic **asymmetry** in the
> information **tracked by each participant**. The replaced states **turn into
> toxic information** as soon as they are replaced, and leaking that
> information may result in funds being stolen. The asymmetry also
> **limits Lightning to two participants**."

There are following points that are not clear to me:

**(1)** Does **asymmetry** mean the information tracked by each participant (payer and recipient) **are NOT the same (or are NOT equal)**?

**(2)** What is the **reason** of this asymmetry?

**(3)** What does "*turn into **toxic** information*" mean?

**(4)** The last sentence: "*asymmetry also limits Lightning to **two participants***", Does it mean that we can expect a payment transaction can have more than two participants? since a payment logically has only two participants: a payer and a recipient.

**Tags:** security, lightning-network, terminology, ln-commitment-transaction, eltoo


---

## 1 answers

### Answer by username_1 on 2019-01-02. Score: 5 | Accepted answer

When two channel participants open a channel or update it, they exchange commitment transactions. These commitment transactions allow each party to unilaterally close the channel.

The commitment transactions are asymmetric in that they lock the closing party's funds when broadcast, i.e. Alice's commitment transaction locks Alice's funds, Bob's commitment transaction locks Bob's funds. The counterparty's funds are immediately available for spending. The lock on the closing party's funds (the "breach remedy") gives the counterparty time to impound the closing party's funds via a "punishment transaction" if an outdated state was broadcast.

[![Illustration of the asymmetric commitment transaction](https://i.sstatic.net/TsLHb.png)](https://i.sstatic.net/TsLHb.png)

***Commitment Transaction** (via [Elle Mouton](https://www.ellemouton.com/blog/view/4)): Alice's output to herself (`to_local`) in her commitment transaction is encumbered with a Revocable Sequence Maturity Contract (RSMC) which allows her to revoke the commitment transaction later, while the output to Bob (`to_remote`) is a simple send, vice versa for Bob's transaction.*

When a payment is made in the channel and the channel is updated with new commitment transactions, the outdated channel state is revoked by revealing the secrets to spend the old commitment transactions (dB1 and dA1 in the graphic). This makes the old state "toxic" in the sense that (accidentally) using the outdated commitment transaction to close the channel will cost the closer all their funds in the channel.

Updating a channel to make a payment in the punishment-based channel setup requires a procedure with multiple roundtrips in a specific order to ensure that there is no disadvantageous intermittent state for either party. If it were possible to map this onto a multiparty setup, it would be extremely complex.

In Eltoo, commitment transactions are shared across the participants. Broadcasting an outdated state is corrected by overwriting it with the latest state. Since the channel state is symmetric, it is trivial to have channels with more than two parties. This could take e.g. the form of four parties creating a four-of-four multisig output to anchor a channel. Each party would have a balance in the channel which they could use to send funds to another channel participant, or other network participants. With Schnorr signatures and key aggregation, such channels would be extremely efficient as they could still fit in the size of a singlesig output. Practically, the number of participants would still be limited as any channel update would have to be agreed upon by every participant, and any one participant wanting to close the channel would close it for all. Possibly, this could be used as a liquidity pool or for [channel factories](https://bitcoin.stackexchange.com/q/67158/5406) among large players that can guarantee continuous availability.

> **Comments:**
> **username_0**: Thank you. Just when you say we can have channels with more than two parties, do you mean that we can have a bidirectional payment channel between e.g. 4 participants (payer/recipient) like this figure? ( https://imgur.com/5KVLP6G ) Or do you mean something else? And does `eltoo` such a capability? Thanks  
> **username_2**: with the current lightning network multiparty channels are theoretically possible but not implemented. in eltoo these channels are much easier to implement because all parties share the same state and update / settlement transactions. Therefor if we switch to eltoo channels one day we will most likely get multiparty channels implemented  
> **username_0**: And in that case (having multiparty channels), we can establish a large channel between participants, such that they do not need to do **multi hop** payments since a direct link exists between them and therefore we do not need to do a **routing** process, isn't it? Do you agree? Thank you.  
> **username_1**: I've amended my answer to give more details on some potential applications for Eltoo.  

---

