[Lightning-dev] Dynamic Commitments: Upgrading Channels Without On-Chain Transactions

[Olaoluwa Osuntokun]

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 <ZmnSCPxj at protonmail.com> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200721/4a762a70/attachment.html>