Good morning aj, > In order to transition from BOLT#3 format to this proposal, an onchain > transaction is required, as the "revocable signatures" arrangement cannot > be mimicked via the existing 2-of-2 CHECKMULTISIG output.
A transaction is required, but I believe it is not necessary to put it *onchain* (at the cost of implementation complexity in the drop-onchain case). An existing channel can "simply" sign a transitioning transaction from the current BOLT3 to your new scheme, and then invalidate the last valid commitment transactions (i.e. exchange revocation secrets) in the BOLT3 scheme. The transitioning transaction can simply be kept offchain and its output used as the funding outpoint of all "internal" (to the two counterparties directly in the channel) states. This general idea would work for all transitions *from* Poon-Dryja, I believe. It may be possible with Decker-Russell-Osuntokun I think (give the transitioning transaction the next sequence `nLockTime` number), but the `SIGHASH_NOINPUT`ness and (maybe?) the `CSV` infects the mechanism being transitioned to, so this technique may be too complicated for transitioning *from* Decker-Russell-Osuntokun to some hypothetical future offchain updatable cryptocurrency system that does not need (or want) `SIGHASH_NOINPUT`. This has the advantage of maintaining the historical longevity of the channel. Many pathfinding and autopilot heuristics use channel lifetime as a positive indicator of desirability, thus an *onchain* transitioning transaction is undesirable as that marks a closure of the previous channel. And the exact scheme of channels between forwarding nodes are not particularly the business of anyone else anyway. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
