Author: Antoine Riard 2020-07-21 23:47:27
Published on: 2020-07-21T23:47:27+00:00
In a recent proposal, Olaoluwa Osuntokun shared an early version of an extension to the Lightning Network specification and channel state machine that would allow for on-the-fly commitment format/type changes. The proposal suggests that if they introduce more commitment types, there may not be a "default" type, so making this process explicit is important to future exploration and extensibility. They may want a "default" type based on the most secure/private one to avoid downgrade attack a la TLS between implementations.To solve the existing ambiguity in the channel type negotiation, it is suggested that they add a new update message (like `update_fee`) to make the process more explicit. In either case, they may want to restrict things a bit by only allowing the initiator to trigger a commitment format update. The proposal also suggests introducing a new `upgrade_channel` message and its handling flow + new TLV in `open/accept`. And then slowly increasing the scope of what you can actually upgrade/negotiate.This post proposes a set of protocol modifications using TLV fields to allow Lightning Network (LN) nodes to upgrade their commitments without any on-chain transactions. Allowing channel types to be upgraded on the fly lets us update the network to the new safer channel types in a de-synchronized, distributed manner that doesn't require any on-chain transactions. Dynamic commitments as a whole also create another point of extensibility in the protocol so we can start to explore all the variants on channels as we know them that exist.The Lightning Network is upgrading its anchor commitment format to improve safety. The new anchor commitment format is the safest format yet, according to a research paper published by the International Association for Cryptologic Research. In order to implement this upgrade, all existing channels involved in the Lightning Network will need to be upgraded as well. This announcement was made on the Lightning-dev mailing list by Laolu.Currently, new channel types are introduced by adding a new feature bit and upgrading is implicit with no explicit signalling during the funding process. This works well if there is only one major accepted "official" channel type but not as new types are introduced for specific use cases or applications. To resolve this ambiguity in the channel type negotiation, a new `channel_type` TLV would be added which makes the channel type used in funding explicit, with the existing feature bit advertisement system being kept in place. The commitment state machine changes would allow us to explicitly identify which channel type we want to enter a funding flow for. The ability to upgrade commitments after the fact lessens the pressure of newer possibly experimental channel types to get all the details correct up front. Once Taproot rolls around, we can simply update the funding output, roll that out, then continue to hash out the details on the possibly new channel type(s) that take advantage of all the new tools.
Updated on: 2023-06-03T01:53:07.954089+00:00