lnwire+funding: introduce new protocol extension for explicit channel type negotiation #5071
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In this commit, we add a new TLV record that's intended to be used as an explicit channel type for a new form of funding negotiation, and later on a dynamic commitment upgrade protocol. As defined, we have 3 channel types: base (the OG), tweakless, and anchors w/ zero fee HTLCs. We omit the original variant of anchors as it was never truly deployed from the PoV of lnd.
In this commit, we add a new ChannelType field as a new TLV record to the open and accept channel messages. During this change, we make a few tweaks to the generic TLV encode/decode methods for the ExtraOpaqueData struct to have it work on the level of tlv.RecordProducer instead of tlv.Record, as this reduces line noise a bit. We also partially undo existing logic that would attempt to "prepend" any new TLV records to the end of the ExtraOpaqueData if one was already present within the struct. This is based on the assumption that if we've read a message from disk to order to re-send/transmit it, then the ExtraOpaqueData is fully populated so we'll write that as is. Otherwise, a message is being encoded for the first time, and we expect all fields that are known TLV fields to be specified within the struct itself. This change required the unit tests to be modified slightly, as we'll always encode a fresh set of TLV records if none was already specified within the struct.
…thods We now use their generic variants in place.
If these bits are present, then both sides can examine the new ChannelType TLV field that's present and use this in place of the existing implicit channel type negotiation. With this change, it's now possible to actually deprecate old unsupported channel types properly.
This field will be examined later down the stack along with the set of feature bits to determine if explicit channel type negotiation is possible or not.
In this commit, we modify the existing logic that defaults to implicit channel type negotiation to support explicit negotiation if the new feature bit is set. This change allows us to ditch the notion of a "default" channel type, as we'll now use feature bits to signal our understanding of a channel type, but allow peers to select which channel type they actually wish to use. In addition, this explicit negotiation removes the need for using the required bit of any channel types. Instead, if an implementation wishes to no longer support a channel type, they should simply stop advertising the optional bit. We also remove the need to "downgrade" our feature bits if we have an old channel type with that peer, as we'll simply reject the legacy channel type if they attempt to use it.
Roasbeef
added
wire protocol
|
Closing in favor of #5373. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In this PR, we put forth a draft implementation of explicit channel type negotiation. Explicit channel type negotiation prepares us for a future where no "default" channel type actually exists. Compared to implicit channel type negotiation, rather than using a set of overlapping feature bits to determine which channel type is being used during funding negotiation, we instead have both sides signal what their desired channel type is to be. This preps us for a future of dynamic commitments as the same channel type reference will be used to change the commitment type in-flight. Additionally, moving to an explicit channel type negotiation gives us a better way to remove unsupported channel types, as we'd simply stop advertising the optional feature bit and reject all attempts to us that channel type.
This PR is still in the draft phase as it's missing a few things including: