rich1.0Anthony Towns [ARCHIVE] (npub17r…x9l2h)https://yabu.me/npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hnjumphttps://yabu.me📅 Original date posted:2021-10-08 📝 Original message: 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. > 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. Cheers, aj