Dynamic Commitments: Upgrading Channels Without On-Chain Transactions [combined summary]



Individual post summaries: Click here to read the original discussion on the lightning-dev mailing list

Published on: 2020-08-23T04:26:16+00:00


Summary:

Rusty, a member of the Lightning Labs squad, has proposed making an initial switch over double-opt-in by adding two new messages: `commit_switch` and `commit_switch_reply`. He suggests retaining the "initiator" only system to handle collisions. Rusty also proposes a linear progression of channel types and dropping older formats at some point. He suggests using existing feature bits to define upgrades and sending `commit_switch` with features to determine new features for the channel. Rusty outlines the conditions for adding HTLCs after sending `commit_switch` and proposes upgrading to anchor_outputs in three steps.ZmnSCPxj proposed an upgrade transaction that transitions from the Poon-Dryja to the Decker-Russell-Osuntokun ("eltoo") mechanism. An adaptor or an upgrade transaction can be created to move from one type to another, and the upgrade transaction is kept off-chain and ignored at mutual close. The channel retains its short-channel ID, which may be useful for pathfinding algorithms.Olaoluwa Osuntokun shared an early version of an extension to the Lightning Network specification and channel state machine that allows for on-the-fly commitment format/type changes. The proposal suggests adding a new update message to make the process explicit and introducing a new `upgrade_channel` message. It also suggests using TLV fields to allow nodes to upgrade their commitments without on-chain transactions.The Lightning Network is upgrading its anchor commitment format to improve safety. All existing channels involved in the Lightning Network will need to be upgraded as well. A new `channel_type` TLV will be added for explicit negotiation of channel types during funding. The ability to upgrade commitments after the fact lessens the pressure of newer channel types. Upgrades can be made once Taproot rolls around.A discussion on the Bitcoin-dev mailing list suggested upgrading from a Poon-Dryja channel to a Decker-Russell-Osuntokun mechanism using an upgrade transaction. The upgrade transaction is kept off-chain and treated as the "internal funding outpoint" for future updates. It has limitations but also benefits such as bounding the information liability of the upgraded channel.The Lightning Network developers proposed dynamic channel updates that allow users to upgrade their existing channels to new, safer types without on-chain transactions. This is done by adding a new feature bit and introducing a new update message. The proposal also suggests modifying the protocol to include explicit channel type negotiation and using TLV fields for more complex channel types.Olaoluwa Osuntokun proposed an extension to the Lightning Network specification and channel state machine that allows for on-the-fly commitment format changes. This modification will make it possible to upgrade existing channels to new safer types without on-chain transactions. A new `channel_type` TLV will be added for explicit negotiation of channel types during funding.ZmnSCPxj proposed upgrading from a Poon-Dryja channel to a Decker-Russell-Osuntokun mechanism through an off-chain update. An upgrade transaction can be created by cutting-through a mutual close of the Poon-Dryja channel and a funding open of a Decker-Russell-Osuntokun channel. The upgrade transaction is kept off-chain and the funding outpoint becomes the "internal funding outpoint" for future updates.A proposal has been made to extend the Lightning Network protocol and channel state machine to allow on-the-fly commitment format changes without on-chain activity. This would enable users to upgrade their existing channels to new safer types. The proposal suggests using TLV message field extensions and modifying the protocol for explicit channel type negotiation.The Lightning Network is proposing a protocol modification that allows nodes to upgrade their commitments without on-chain transactions. This provides a point of extensibility in the protocol and allows for exploration of new channel types. The proposal relies on TLV message extensions and allows for easier and more seamless channel upgrades.Bastien Teinturier expressed interest in experimenting with flow-control ideas such as limiting the number of HTLC slots for new channel peers. The Lightning Labs team is committed to exploring this direction to upgrade all existing channels to the new anchor commitment format.Olaoluwa Osuntokun proposed an extension to the Lightning Network specification and channel state machine to allow on-the-fly commitment format or type changes. This modification will enable users to upgrade their existing channels without new on-chain transactions. The proposal suggests adding a new `channel_type` TLV, introducing new messages, and using TLV fields for more complex channel types.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.


Updated on: 2023-07-31T22:59:16.963458+00:00