Good morning Rene,
The main issue I can think of offhand is the below issue for duplex channels:
The maximum lockup period for your funds in the worst case is proportional to
the number of updates the channel can have. Shorter worstcase lockup, fewer
updates before the channel can only be closed. There is a technique to make
O(log n) lockup time for n update limit rather than O(n) (at the cost of using
O(log n) transactions in sequence), but the basic "more updates more worstcase
lockup" exists. With Poon-Dryja (revocation) channels, there is no limit in
the number of updates possible on a channel, especially when you use the
"shachain" concept by Rusty Russell (which reduces storage for a sequence of
revocation keys to just 64 bytes or so, I have not studied it deeply): in
effect, you get O(1) lockup time and O(1) transactions for n update limit under
Poon-Dryja rather than O(log n) lockup time and O(log n) transactions for
Decker-Wattenhofer.
Note in particular that every payment actually requires two updates: one to get
payer funds to an HTLC, and the other to get the HTLC funds to the payee (or to
revert the HTLC funds to the payer in case of routing failure). This is needed
to get proof-of-payment and in particular to ensure that the final payee on a
long route really did get the funds. So the cost incurred by
Decker-Wattenhofer is higher by that factor, too.
Decker-Wattenhofer does have the advantage that its construction can be
extended to any number of participants per channel, while Poon-Dryja does not
seem like it can be easily extended beyond two per channel. Hence the
Burchert-Decker-Wattenhofer channel factories, where a Decker-Wattenhofer
multiparticipant channel construction terminates into multiple two-participant
Poon-Dryja channels. The Poon-Dryja channels can have any number of updates,
and the Decker-Wattenhofer part only gets updated if all participants agree to
redistribute their funds between terminating Poon-Dryja channels (which we
expect to happen much more rarely than routing and sending/receiving funds, so
that the O(log n) cost for maximum number of updates is less onerous for fund
redistribution, while we still get to enjoy the potentially infinite number of
possible channel updates for individual Poon-Dryja channels).
Regards,
ZmnSCPxj
Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On March 4, 2018 7:30 AM, René Pickhardt via Lightning-dev
<[email protected]> wrote:
> Hey everyone,
>
> as mentioned before I am quite new to lightning dev. Should the questions
> I'll ask be too basic please drop me a kind note and I will be more quite or
> ask my questions on other places.
>
> Today I studied Chrstian Deckers nice work about duplex micropayment channels
> (
> [http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf](https://www.google.com/url?q=http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf&sa=D&source=hangouts&ust=1520200459037000&usg=AFQjCNG3ZwxZzV6e3VYlLpemzn0ZCUIv-A)
> )
>
> I am wondering what was the rational for the lightning spec (
> https://github.com/lightningnetwork/lightning-rfc ) to go with the revocation
> key system instead of the solution by Christian Decker to the problem? I
> understand that the revocation system was already in the whitepaper and at
> the time of writing the whitepaper the work by Christian Decker wasn't out
> yet. But I guess this will not be the entire reason.
>
> To me the key revocation system seems pretty complex to handle. In particular
> as Rusty also mentioned on his article (c.f.
> https://medium.com/@rusty_lightning/lightning-watching-for-cheaters-93d365d0d02f
> ) that already in the white paper people knew that potentially a third party
> observing service to detect a cheater is needed. This seems to me like a big
> drawback.
>
> So what have been strong arguments to go with the revocation system?
>
> On a side note I would like to state my respect to you: The lightning network
> (in combination with bitcoin) is really the most beautiful piece of
> technology I came across since I learnt about TCP/IP. Great work everybody
> for creating such an amazing technology and bringing together all those
> beautiful ideas. I am very confident that this technology will become history.
>
> best Rene
>
> --
> [www.rene-pickhardt.de](http://www.rene-pickhardt.de/)http://www.beijing-china-blog.com/
>
> Skype: rene.pickhardt
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
