Author: Bastien TEINTURIER 2020-07-21 08:46:12
Published on: 2020-07-21T08:46:12+00:00
A proposal has been made to extend the Lightning Network protocol and channel state machine. The proposal suggests allowing for on-the-fly commitment format/type changes without any on-chain activity. This can be executed in a de-synchronized and distributed manner. With dynamic commitments, users can upgrade their existing channels to new safer types without any new on-chain transactions.Anchor output-based commitments represent a step forward in making channels safer. They allow users/software to no longer have to predict chain fees ahead of time. Also, bump up the fee of a commitment/2nd-level-htlc-transaction, which is extremely important when it comes to timely on-chain resolution of HTLC contracts.The ability to update the commitment format itself will also allow us to re-parametrize portions of the channels that are currently set in stone. For example, right now, the number of max allowed outstanding HTLCs is set in stone once the channel has opened. With the ability to swap out commitment parameters, we can start to experiment with flow-control ideas such as limiting a new channel peer to only a handful of HTLC slots, which is then progressively increased based on "good behavior".Beyond just updating the channel parameters, it's also possible to "change the rules" of a channel on the fly. An example of this variant would be creating a new pseudo-type that implements a fee policy other than "the initiator pays all fees". To resolve the ambiguity in the channel type negotiation, a new proposal suggests making the channel type used for funding explicit. This can be achieved through the addition of a `channel_type` TLV field in the `open_channel` and `accept_channel` messages. Retroactively, the OG commitment format is numbered as `channel_type=0`, static_remote_key as `channel_type=1`, and anchors as `channel_type=2`. The proposal involves introducing a series of small changes to the commit_sig and revoke_and_ack messages which allow us to implement the "dynamic" portion of the proposal. By exchanging four messages, both sides are able to upgrade to a new commitment format. However, one issue with the above flow is that it currently isn't allowed by the spec since we disallow sending a commit_sig message that doesn't cover any updates.To prepare for these changes, implementations need to be able to handle "holding" unrevoked commitments of heterogeneous types, as if either of them hit the chain, they'll need to be able to resolve all contracts properly. Allowing channel types to be upgraded on the fly allows us to update the network to the new safer channel types in a de-synchronized, distributed manner that doesn't require any on-chain transactions.During funding negotiation, the commitment type itself is parametrized based on the channel_type value. With these changes, commitment state machine changes are also introduced to explicitly identify which channel type to enter a funding flow for. As more types are added, there may not be a default type, so making this process explicit is important to future exploration and extensibility.If one receives an open_channel or accept_channel message with an unknown channel_type, they are to fail the funding flow. Nodes must not send an open_channel or accept_channel message with a channel_type that isn't covered by their existing advertised feature bits, and a mapping between feature bits and expected channel_type values would then be added. In either case, only the initiator will be allowed to trigger a commitment format update. Updating the commitment format should be a rare enough operation that we can afford to synchronize with a two-way `update_commitment_format` handshake, then temporarily freeze the channel. The tricky part will be how to handle "dangling" operations that were sent by the remote peer after the initiator sent the `update_commitment_format`.
Updated on: 2023-06-03T01:50:33.684630+00:00