Roadmap for new commitment formats and old commitment formats clean-up

[t-bast]

We currently support the following commitment formats:

• default (OG lightning v1.0 channels) : we don't accept new channels of that type but may have existing channels
• static remote key : we don't accept new channels of that type but may have existing channels
• anchor outputs with 0-fee htlcs : this is the preferred commitment format that all other implementations support
• anchor outputs with fee-paying htlcs : this is only used for mobile wallets who can't broadcast 0-fee HTLC txs

Each of those commitment formats has subtle changes compared to the others, that can affect funds safety. It would be hard to maintain an exhaustive test matrix if we keep adding new commitment formats without the ability to remove old ones.

In the near future, we'd like to add support for:

• v3 anchor output channels: improves force-close safety and reduces fees compared to anchor outputs
• taproot channels: improves privacy and reduces fees compared to anchor outputs
• taproot v3 channels: combines the two previous commitment formats

To avoid creating too much technical debt, we plan on gradually releasing new commitment formats while deprecating previous commitment formats:

• our first step will be to implement taproot channels, but restrict it to internal use with phoenix
  • with small (unreleased) changes, this will let us test compatibility with lnd's implementation of taproot channels to validate the BOLT spec
  • once deployed to phoenix, we will actively migrate existing anchor outputs channels to taproot
  • we will also stop accepting anchor outputs with fee-paying htlcs channels (users have to update their app)
  • this lets us test taproot channels in the wild before officially supporting them in eclair
  • at that point, we could also stabilize our swap-in-potentiam implementation and move it to master (with a corresponding bLIP)
• after that, we'll remove support for default channels and static remote key channels:
  • we should notify node operators right now that they should close those channels now that the feerate is low and open anchor output channels instead
    • done before the 0.13.0 release
  • we should find a mechanism to prevent eclair from starting up at that point if it has active channels of one of those commitment formats (before potentially migrating codecs or updating DB tables), to allow node operators to keep using the previous version of eclair to close those channels before updating
    • done in Remove legacy channel codecs #3150
  • we will also remove support for channel codecs older than v3 (and maybe a few very old DB table schemas)
    • done in Remove legacy channel codecs #3150
• after that, we will add support for v3 anchor output channels
  • this will become the preferred commitment format: all implementations have signaled that they would implement it as soon as possible
  • which should eventually allow us to remove support for v2 anchor output channels
  • at that point, depending on the phoenix rollout, we may remove support for anchor outputs with fee-paying htlcs
• after that, we will add supports for v3 taproot channels
  • this allows using the key path for revocation everywhere (compared to v2 taproot channels) and remove the NUMS point
  • it makes all scripts miniscript-compatible, which is nice
  • this will become the preferred commitment format, but it may take a while for other implementations to support it, so we will have to keep supporting at least anchor output v3 channels in parallel
• cleaning up phoenix channels using obsolete commitment formats:
  • after a large enough migration window (6-12 months), we should actively force-close phoenix channels that don't use taproot
  • on the lightning-kmp side, we should only keep minimal support for previous commitment formats, to only handle force-closing them and getting funds back (potentially into a modern channel)

[t-bast]

TODO: provide API command to let a node operator check whether they have default or static_remotekey channels that need to be closed and notify on telegram/twitter

[t-bast]

An interesting note from #3075: once we stop supporting static_remotekey, we can simplify LocalCommitPublished and RemoteCommitPublished because it's useless to store the 0-fee HTLC txs which we recompute on-the-fly and forward to the transaction publisher actors to set fees and sign. We can instead simply store a set of the HTLC outpoints that we should watch.

[viaj3ro]

TODO: provide API command to let a node operator check whether they have default or static_remotekey channels that need to be closed and notify on telegram/twitter

does this API command exist already? couldn't find it in the documentation

[t-bast]

This hasn't been documented yet because it will change once #3118 is integrated, which we want to do before the next release. Once we merge #3118 and release the next version of eclair, we will document the corresponding command, which will be:

eclair-cli channels | jq '.[] | { channelId: .data.commitments.channelParams.channelId, commitmentFormat: .data.commitments.active[].commitmentFormat }' | jq 'select(.["commitmentFormat"] == "legacy")'

[t-bast]

@viaj3ro this has been documented in the v0.13.0 release.