-
Notifications
You must be signed in to change notification settings - Fork 421
Remove redundant ChannelContext::channel_type
#3678
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
👋 Thanks for assigning @wpaulino as a reviewer! |
9b2a4a8 to
8509d0b
Compare
dunxen
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Makes sense to have it under funding scope only.
8509d0b to
cb31af3
Compare
While channel_type_features won't change during splicing, they may change when migrating existing channels to taproot in the future.
cb31af3 to
6490e39
Compare
|
Rebased on main to avoid being blocked by #3651. |
wpaulino
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM but CI is sad
FundingScope::get_channel_type can be used instead of ChannelContext::channel_type, which is redundant.
6490e39 to
b036a94
Compare
|
Pushed a fix for CI. |
|
CI is sad |
When reading ChannelTransactionParameters, the channel_type_features defaults to only_static_remote_key. This is similarly the case for reading a channel. Instead of overriding the latter with the former, check that they are consistent. It doesn't appear that overriding was ever necessary.
54ebb06 to
1bb3b4d
Compare
|
Merging as CI failure seems unrelated: |
A channel's type is duplicated in
ChannelContext::channel_typeandFundingScope, viaChannelTranscationParameters::channel_type_features. Remove the redundantChannelContext::channel_typeand useFundingScope::get_channel_typeinstead. While the type will be the same across allFundingScope's during splicing, this may not be the case in the future when migrating existing channels to taproot.Based on #3651.