From ZmnSCPxj at protonmail.com Sat Oct 9 02:27:37 2021 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Sat, 09 Oct 2021 02:27:37 +0000 Subject: [Lightning-dev] Lightning over taproot with PTLCs In-Reply-To: <20211009021519.GB4108@erisian.com.au> References: <20211009011207.GA3984@erisian.com.au> <20211009021519.GB4108@erisian.com.au> Message-ID: 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