[epic]: Dynamic Commitment Roadmap

[yyforyongyu]

This is the master tracking issue for implementing dynamic commitments. Based on my current understanding after playing it out a bit, this project is split into four stages so it's easier to track the progress.

Stage One - Preparation

We will clean up existing PRs and create new PRs to prepare for the upcoming dynamic commitment work. These PRs can be merged directly into the master branch as they won't affect existing functionality.

• DynComms [2/n]: lnwire: add authenticated wire messages for Dyn* #9148 - rebase and merge, minor fixes needed in the test area.
• finalize Quiesce - Enable quiescence in production and add timeout config #10001
• minor refactor in htlcswitch, specifically the link, to make the existing flow cleaner. - Refactor link's long methods #10018
• minor change in the dyn msg set - we want to use BigSize instead. - Fix ExtraData field and use BigSize encodine #10027

Stage Two - Finalizing Specs

We will address all comments in this PR lightning/bolts#1117, finalize the TODOs in that draft, and create a new draft with some potential improvements based on my experiment.

• fix typos and formats in Extension/dynamic commitments lightning/bolts#1117, and open a new PR - will keep it in my repo for discussion first.
• address existing comments in this new draft.
• update the existing dyn flow to reduce communication rounds - Finalize dynamic commitments for channel params yyforyongyu/bolts#2
• potentially remove the kickoff txns, will write up the details - Draft: Finalize dynamic commitments for channel type yyforyongyu/bolts#3
• there's no protocol-level defined exit behavior for quiescence, which means we need to explicitly define it in the dyn specs, unless we could instead have a msg that signals the ending of quiescence (previous attempt was vetoed).

Stage Three - Channel Params Upgrade

We will begin the implementation in this stage, with the focus on upgrading channel params first.

• create a design doc for the internal dynamic commitment flow. Design Doc for Dynamic Commitments #10076
• create a design doc for the RPC, focusing on how this endpoint is intended to be used. Design Doc for Dynamic Commitments #10076
• minor refactor on channeldb/channel.go, mostly just moving code into a new file.
• minor refactor on rpcserver.go, again just moving code for clarity.
• enable updating channel config in OpenChannel - will need to persist commitHeight:oldConfig on disk.
• build dynamic commitment upgrader based on the design doc.
• mount the upgrader to the channel link.
• update the revocation flow to locate the old config.
• gossip channel_update - need to double check whether the channel is disabled when entering quiescence.
• update watchtower?
• build the RPC.
• build itest cases.

Stage Four - Commitment Type Upgrade

This will be the most involved part; however, implementing channel params upgrade first should give us a skeleton to work with at this stage. It also depends on the final spec - if we assume the simplified version works, the changes are,

• minor refactor in lnwallet/reservation.go - need to extract the logic used to convert lnwire.ChannelType and channeldb.ChannelType.
• minor refactor in lnwallet/channel.go - separate funding type and commitment type.
• extend existing dynamic commitment flow to enable commitment type upgrade.
• extend the RPC.
• build itest cases.

This is a rough estimate - its final scope depends on the outcome from stage two.

Open Questions

• dynamic commitments on zero-conf channel should not be allowed when it's unconfirmed?
• should we use this opportunity to allow changing a public chan into a private one? See [feature]: Turn a private into a public channel #7902 and [feature]: change openchannel to make private channels by default #9157.

[Roasbeef]

potentially remove the kickoff txns, will write up the details.

Do you mean all together, or that you've found another way to handle the case where we need to change the funding output? The last iteration we did there was to separate the kick off vs non kick off case in the tests.

[yyforyongyu]

Channel params specs is ready for review - yyforyongyu/bolts#2

Do you mean all together, or that you've found another way to handle the case where we need to change the funding output? The last iteration we did there was to separate the kick off vs non kick off case in the tests.

What tests? So the idea is to upgrade the commitment format instead, moving the discussion here - yyforyongyu/bolts#3

[saubyk]

should we use this opportunity to allow changing a public chan into a private one?

Wondering what you have in mind to affect this.
A public channel would already be in the graph of the nodes, if it's made private post facto, how would that channel be removed from other node's graphs? Or are you suggesting a new chan id instead?