From laolu32 at gmail.com Tue Jul 21 22:55:54 2020 From: laolu32 at gmail.com (Olaoluwa Osuntokun) Date: Tue, 21 Jul 2020 15:55:54 -0700 Subject: [Lightning-dev] Dynamic Commitments: Upgrading Channels Without On-Chain Transactions In-Reply-To: References: Message-ID: Hi Z, > Probably arguably off-topic, but this post triggered me into thinking > about an insane idea: offchain update from existing Poon-Dryja to newer > Decker-Russell-Osuntokun ("eltoo") mechanism. Ooo, yeh I don't see why this would be possible assuming at that point no_input has been deployed... However, switching between commitment types that have distinct commitment invalidation mechanisms appears to make things a bit more complex. Consider that since the earlier lifetime of my channel used _revocation_ based invalidation, I'd need to be able to handle two types of invalid commitment broadcasts: broadcast of a revoked commitment, and broadcast of a _replaced_ commitment. As a result, implementations may want to limit the types of transitions to only a commitment type with the same invalidation mechanism. On the other hand, I don't think that additional complexity (being able to handle both types of contract violations) is insurmountable. For those that wish to retain a revocation based commitment invalidation model, they may instead opt to upgrade to something like this [1], which I consider to be the current best successor to the OG Poon-Dryja revocation mechanism (has some other tool traits too). The commitment format still needs a sexy name though...."el tres"? ;) > We can create an upgrade transaction that is a cut-through of a mutual > close of the Poon-Dryja, and a funding open of a Decker-Russell-Osuntokun. Splicing reborn! > The channel retains its short-channel-id, which may be useful, since a > provably-long-lived channel implies both channel participants have high > reliability (else one or the other would have closed the channel at some > point), and a pathfinding algorithm may bias towards such long-lived > channels. Indeed, I think some implementations (eclair?) factor in the age of the channel they're attempting to traverse during path finding. [1]: https://eprint.iacr.org/2020/476 -- Laolu On Tue, Jul 21, 2020 at 7:50 AM ZmnSCPxj wrote: > Good morning Laolu, and list, > > Probably arguably off-topic, but this post triggered me into thinking > about an insane idea: offchain update from existing Poon-Dryja to newer > Decker-Russell-Osuntokun ("eltoo") mechanism. > > Due to the way `SIGHASH_ANYPREVOUT` will be deployed --- requires a new > pubkey type and works only inside the Taproot construction --- we cannot > seamlessly upgrade from a Poon-Dryja channel to a Decker-Russell-Osuntokun. > The funding outpoint itself has to be changed. > > We can create an upgrade transaction that is a cut-through of a mutual > close of the Poon-Dryja, and a funding open of a Decker-Russell-Osuntokun. > This transaction spends the funding outpoint of an existing Poon-Dryja > channel, and creates a Decker-Russell-Osuntokun funding outpoint. > > However, once such an upgrade transaction has been created and signed by > both parties (after the necessary initial state is signed in the > Decker-Russell-Osuntokun mechanism), nothing prevents the participants > from, say, just keeping the upgrade transaction offchain as well. > > The participants can simply, after the upgrade transaction has been > signed, revoke the latest Poon-Dryja state (which has been copied into the > initial Decker-Russell-Osuntokun state). > Then they can keep the upgrade transaction offchain, and treat the funding > outpoint of the upgrade transaction as the "internal funding outpoint" for > future Decker-Russell-Osuntokun updates. > > Now, of course, since the onchain funding outpoint remains a Poon-Dryja, > it can still be spent using a revoked state. > Thus, we do not gain anything much, since the entire HTLC history of the > Poon-Dryja channel needs to be retained as protection against theft > attempts. > > However: > > * Future HTLCs in the Decker-Russell-Osuntokun domain need not be recorded > permanently, thus at least bounding the information liability of the > upgraded channel. > * The channel retains its short-channel-id, which may be useful, since a > provably-long-lived channel implies both channel participants have high > reliability (else one or the other would have closed the channel at some > point), and a pathfinding algorithm may bias towards such long-lived > channels. > > Of note, is that if the channel is later mutually closed, the upgrade > transaction, being offchain, never need appear onchain, so this potentially > saves blockchain space. > > Regards, > ZmnSCPxj > -------------- next part -------------- An HTML attachment was scrubbed... URL: