-
Notifications
You must be signed in to change notification settings - Fork 266
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
Add channel type feature bit #2073
Conversation
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.
Do I understand correctly that we don't use the feature bit in our code because we will always set the tlv? But then:
- shouldn't we add a check at startup that forces the feature bit to be enabled?
- shouldn't we check the remote feature bit and reject if the feature bit is set and there is no corresponding tlv?
Yes, that is correct, because the spec allows it and it's an odd tlv.
We could indeed, I'll add that.
We could. I thought it would better to be lenient here because we automatically fallback to the most probable channel type based on feature bits, which will very likely work, but I can change that. |
We already support channel types, but we make it explicit with a feature bit as required by lightning/bolts#906
7755e59
to
0bd5017
Compare
When the feature bit is set, they must provide a channel type.
a4d0706
to
74baf90
Compare
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
We already support channel types, but we make it explicit with a feature bit as required by lightning/bolts#906