From aj at erisian.com.au Sat Oct 9 02:15:19 2021 From: aj at erisian.com.au (Anthony Towns) Date: Sat, 9 Oct 2021 12:15:19 +1000 Subject: [Lightning-dev] Lightning over taproot with PTLCs In-Reply-To: References: <20211009011207.GA3984@erisian.com.au> Message-ID: <20211009021519.GB4108@erisian.com.au> 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