From ZmnSCPxj at protonmail.com Mon Mar 5 13:28:49 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Mon, 05 Mar 2018 08:28:49 -0500 Subject: [Lightning-dev] Christian Deckers Duplex Micropayment Channels vs Lightning networks revocation key solution In-Reply-To: References: Message-ID: 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 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: