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
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
