From ZmnSCPxj at protonmail.com Mon Mar 5 13:50:10 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Mon, 05 Mar 2018 08:50:10 -0500 Subject: [Lightning-dev] Christian Deckers Duplex Micropayment Channels vs Lightning networks revocation key solution In-Reply-To: References: Message-ID: Good morning Rene, >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. I believe this is also necessary under Decker-Wattenhofer? A potential thief trying to reuse old invalid state could make sure you will be offline for a few days, then broadcast (and hope it confirms) the kickoff transaction, wait for the old invalid state to be valid, and then broadcast the old invalid commitment transaction. You have to be online after the kickoff transaction gets confirmed to ensure you can broadcast the latest commitment transaction, too, or if you plan to be offline for long, you also need some watchtower-like service under Decker-Wattenhofer. And I believe that watchtowers under Poon-Dryja need only store the shachain and the funding txid, while watchtowers under Decker-Wattenhofer would have to store entire relative-timelocked transactions, leaking economic information at each update to a Decker-Wattenhofer watchtower, whereas Poon-Dryja watchtowers need to learn only about shachain updates, and can learn economic information only when channels get onchain (and honestly, when channels drop onchain everyone knows the economic information since the blockchain is publicly readable, so it is not a significant information at that point). Regards, ZmnSCPxj -------------- next part -------------- An HTML attachment was scrubbed... URL: