[Lightning-dev] Lightning over taproot with PTLCs

[ZmnSCPxj]

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