Good morning laolu,
> 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.
What I am proposing is that there is an adaptor, an upgrade transaction, which
transitions from one type to the other.
This is needed in transitioning to the Decker-Russell-Osuntokun case anyway,
since as mentioned, current Poon-Dryja channels use P2WSH while
`SIGHASH_ANYPREVOUT`, which Decker-Russell-Osuntokun absolutely relies on, will
only be available on Taproot outputs.
Then, the only thing you need to watch for will be old state for the *oldest*
mechanism the channel had (i.e. the mechanism used at the time of channel
construction), OR the upgrade transaction.
When you see the upgrade transaction onchain, you then switch to watching for
the next-oldest mechanism of the channel.
If a third mechanism is implemented for channels on Lightning as well and this
channel is upgraded again from Decker-Russell-Osuntokun to this third
mechanism, then at this point you switch to watching for revoked states of
Decker-Russell-Osuntokun OR the 2-to-3 upgrade transaction.
> 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"? ;)
Interesting, will check.
Calling it Aumayr-Ersoy-Erwig-Faust-Hostakova-Maffei-Moreno-Sanchez-Riahi seems
fine to me. :P
> > 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!
Not quite splicing: the issue with splice-in (and only splice-in, splice-out is
trivial) is that there is another UTXO being spent, which can invalidate the
transaction that does the splice-in, and leave the channel in limbo.
This upgrade transaction is a 1-input 1-output transaction, spending from the
previous funding outpoint for a particular channel mechanism, and then creating
a new funding outpoint.
The trick is that the upgrade tranaction is ***not*** broadcast (i.e. we do not
close and reopen the channel), it is kept offchain in your database, waiting to
be lost by disk failure like all the other important data, and at mutual close
the upgrade transaction can be ignored.
The node only needs to keep watching for theft attempts on the *oldest*
mechanism the channel has, as the upgrade transaction appearing onchain signals
when the node has to switch over to watching for the newer mechanism(s).
>
> > 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.
>
Indeed, which is why you might want to upgrade a Poon-Dryja to a
Decker-Russell-Osuntokun.
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
