Draft: Finalize dynamic commitments for channel type

[yyforyongyu]

Will focus on channel type conversions that don't need kickoff txns.

I did some experiment here to use a hybrid approach to upgrade an anchor channel to STC. This approach works without broadcasting any onchain txns, instead, it directly updates the next commitment tx to use the taproot outputs. Implementation-wide it seems simpler as,

• if the goal is to allow people routing taproot HTLCs, this achieves it without any onchain footprint. We also don't need to worry about gossip since STCs are private channels.
• we can then use splicing instead for future upgrades like PTLCs and the new gossip.
• implementation-wise it also seems easier - we only need to separate signing the funding output and signing the commitment txns to allow a hybrid channel like P2WSH funding output + taproot commitment outputs. Then we just keep the commitments in the revocation log as it is.

There are also downsides,

• it seems a bit ugly to have a hybrid channel, where we now break the channel_type into funding_type and commitment_type, not sure if it's an abstraction violation.
• we need to remember this change in the watchtower, sth like at commitment height X the outputs are taproot.
• it may have an impact on 3rd party tools to correctly identify and display the state of these channels.
• can we reuse the basepoints? is it cryptographically secure?

Given the discussion here and here, we want to instead use splicing to perform funding output upgrade. Also chatted with Gemini, it seems to like the offchain upgrade approach, but also favors splicing in the long term. (Unfortunately the workspace account doesn't allow sharing conversation via a link, so I created this gist).

Looking for feedback here, meanwhile will implement channel params upgrade first.

[Crypt-iQ]

I haven't followed development in a while, so might be out-dated.

can we reuse the basepoints? is it cryptographically secure?

The Taproot BIP says this is not safe, but I am not a cryptographer so ...?

channel_id || u64(next_commitment_number) || dyn_propose_tlvs

It's probably not possible, but I would just double-check that it's not possible for a node to accidentally sign something that can be interpreted as a node announcement and broadcast across the network. Probably not a concern.

I don't have an opinion on the kickoff vs no-kickoff except that implementation wise keeping track of a hybrid channel seems complicated. The kickoff transaction is a bit annoying especially with pinning. I'm not sure if it has been brought up, but is it possible to use a kickoff tx that is a v3 transaction with a single ephemeral anchor?