<p>As of today, (November 2018):</p>

<blockquote>
  <p>To what extent are those criticisms of Lightning valid as of November 2017?</p>
</blockquote>

<p>This is still a case for Lightning. <a href="https://www.google.com/search?client=ubuntu&amp;channel=fs&amp;q=eltoo%20pdf&amp;ie=utf-8&amp;oe=utf-8" rel="nofollow noreferrer">Eltoo</a> was the first to suggest a simpler way of coping with such storage requirement. They do not require storing keys or older transactions. Their disadvantage is that there is no punishment in the event of fraud, leading to selfish users always publishing the transaction that maximises their balance. In current Lightning Implementations, it is important to keep track of Breach Remedy Transactions, and of course never lose new Commitment Transactions (as this can incur in a punishment to oneself after publishing an old balance unknowingly). </p>

<blockquote>
  <p>Is there an implementation of Duplex micropayment channels or at least plans to create one?</p>
</blockquote>

<p>Current implementations are focusing in Lightning Channels for two main reasons:
1. Eltoo channels are too recent (perhaps somebody is working publicly in an implementation, I am not aware)
2. DMC channels have a trade-off between the utility of the channel and the worst-case collateral cost of the channel, that discourages its use. This is even more important when considering n parties (such as factories). For more information about this trade-off, see the results <a href="https://eprint.iacr.org/2018/918.pdf" rel="nofollow noreferrer">in this document</a></p>

<p>DMCs are however better when one knows of a period of time that one will be offline, so I believe it will be implemented in the future. But there is no current implementation in the main ligthning development teams.</p>

CC BY-SA 4.0
2018-11-14T14:55:17.400Z
2018-11-14T14:55:17.400Z
ranchalp
<p>A <a href="https://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf" rel="nofollow noreferrer">paper</a> from 2015 by Decker and Wattenhofer proposes an interesting design for a payment channel network, which differs from the Lightning network. The authors claim in the Related work section that Lightning:</p>

<ul>
<li>"<em>requires exchanging keying material for each update in the channels, which results in either massive storage or computational requirements</em>", and</li>
<li>"<em>cannot be decomposed into smaller units that can be analyzed in isolation, making the security analysis difficult and resulting in complex implementations</em>".</li>
</ul>

<p>I have two questions:</p>

<ol>
<li>To what extent are those criticisms of Lightning valid as of November 2017?</li>
<li>Is there an implementation of Duplex micropayment channels or at least plans to create one?</li>
</ol>

<lightning-network><micropaymentchannels>
Duplex micropayment channels: criticisms of Lightning and implementation
Sergei Tikhomirov
# Duplex micropayment channels: criticisms of Lightning and implementation

(Asked by: username_0 on 2017-11-27)

A [paper](https://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf) from 2015 by Decker and Wattenhofer proposes an interesting design for a payment channel network, which differs from the Lightning network. The authors claim in the Related work section that Lightning:

* "*requires exchanging keying material for each update in the channels, which results in either massive storage or computational requirements*", and
* "*cannot be decomposed into smaller units that can be analyzed in isolation, making the security analysis difficult and resulting in complex implementations*".

I have two questions:

1. To what extent are those criticisms of Lightning valid as of November 2017?
2. Is there an implementation of Duplex micropayment channels or at least plans to create one?

**Tags:** lightning-network, micropaymentchannels


---

## 1 answers

### Answer by username_1 on 2018-11-14. Score: 2 | Accepted answer

As of today, (November 2018):

> To what extent are those criticisms of Lightning valid as of November 2017?

This is still a case for Lightning. [Eltoo](https://www.google.com/search?client=ubuntu&channel=fs&q=eltoo%20pdf&ie=utf-8&oe=utf-8) was the first to suggest a simpler way of coping with such storage requirement. They do not require storing keys or older transactions. Their disadvantage is that there is no punishment in the event of fraud, leading to selfish users always publishing the transaction that maximises their balance. In current Lightning Implementations, it is important to keep track of Breach Remedy Transactions, and of course never lose new Commitment Transactions (as this can incur in a punishment to oneself after publishing an old balance unknowingly).

> Is there an implementation of Duplex micropayment channels or at least plans to create one?

Current implementations are focusing in Lightning Channels for two main reasons:
1. Eltoo channels are too recent (perhaps somebody is working publicly in an implementation, I am not aware)
2. DMC channels have a trade-off between the utility of the channel and the worst-case collateral cost of the channel, that discourages its use. This is even more important when considering n parties (such as factories). For more information about this trade-off, see the results [in this document](https://eprint.iacr.org/2018/918.pdf)

DMCs are however better when one knows of a period of time that one will be offline, so I believe it will be implemented in the future. But there is no current implementation in the main ligthning development teams.


---

