rich1.0ZmnSCPxj [ARCHIVE] (npub1g5…3ms3l)https://yabu.me/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lnjumphttps://yabu.me📅 Original date posted:2021-10-08 📝 Original message: Good morning aj, > On Sat, Oct 09, 2021 at 01:49:38AM +0000, ZmnSCPxj wrote: > > > 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). > > The trick with that is that if you don't put it on chain, you need > to calculate the fees for it in advance so that they'll be sufficient > when you do want to put it on chain, and you can't update it without > going onchain, because there's no way to revoke old off-chain funding > transactions. Yes, onchain fees, right? *Assuming* CPFP is acceptable, then fees for the commitment tx on the new scheme (or whatever equivalent in the transitioned-to mechanism is) would pay for the transitioning transaction, so fees paying for the transitioning transaction can still be adjusted at the transitioned-to updatable mechanism. This probably assumes that the transaction package relay problem is fixed at the base layer though. > > > 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, > > Maybe that's a good reason for routing nodes to do shadow channels as > a matter of course -- call the currently established channel between > Alice and Bob "C1", and leave it as bolt#3 based, but establish a new > taproot based channel C2 also between Alice and Bob. Don't advertise C2 > (making it a shadow channel), just say that C1 now supports PTLCs, but > secretly commit to those PTLCs to C2 instead C1. Once the C2 funding tx > is buried enough, start advertising C2 instead taking advantage of its > now sufficiently buried funding transaction, and convert C1 to a shadow > channel instead. > > In particular, that setup allows you to splice funds into or out of the > shadow channel while retaining the positive longevity heuristics of the > public channel. Requires two UTXOs, though, I think? How about just adding a gossip message "this new short-channel-id is the same as this old short-channel-id, use the new-short-channel-id to validate it but treat the age as that of the old short-channel-id"? Regards, ZmnSCPxj