ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2020-07-21 📝 Original message: Good morning laolu, > Hi ...
📅 Original date posted:2020-07-21
📝 Original message:
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
📝 Original message:
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