Dynamic Commitments: Upgrading Channels Without On-Chain Transactions



Summary:

Rusty, a member of the Lightning Labs squad, has written about making an initial switch over double-opt-in, which would involve adding two new messages: `commit_switch` and `commit_switch_reply`. In terms of etiquette, he suggests retaining the "initiator" only system. If both parties can initiate, then collisions would need to be handled. Rusty also proposes a linear progression of channel types, with type n+1 always preferred over type n, thereby reducing the test matrix at some point by dropping older formats. While inventing a new commitment type numbering scheme is deemed unnecessary, Rusty suggests using existing feature bits and defining what upgrades are permissible. He proposes sending `commit_switch` with features and doing feature matching to determine new features for the channel. Upgrades will be a noop if one requires a feature that the other doesn't offer, or if the combination offers no new features. Rusty outlines the conditions for adding HTLCs after sending `commit_switch`. He proposes upgrading to anchor_outputs in three steps: releasing support for anchor_outputs, supporting upgrading to anchor_outputs, and requiring anchor_outputs, unilaterally closing channels without (ideally very few!). A feature bit for upgrades is needed, and Rusty wonders whether anyone is working on this right now.


Updated on: 2023-06-03T01:48:15.410574+00:00