From ZmnSCPxj at protonmail.com Tue Jul 21 14:50:39 2020 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Tue, 21 Jul 2020 14:50:39 +0000 Subject: [Lightning-dev] Dynamic Commitments: Upgrading Channels Without On-Chain Transactions In-Reply-To: References: Message-ID: 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