Skip to content
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

option_channel_type was negotiated but channel_type is missing #6067

Closed
joostjager opened this issue Dec 7, 2021 · 4 comments · Fixed by #6075
Closed

option_channel_type was negotiated but channel_type is missing #6067

joostjager opened this issue Dec 7, 2021 · 4 comments · Fixed by #6075
Labels
channels interop interop with other implementations
Milestone

Comments

@joostjager
Copy link
Contributor

joostjager commented Dec 7, 2021

Background

Cannot open a channel to Eclair

Your environment

Steps to reproduce

  • Connect Eclair to LND
  • LND initiates channel open via lncli openchannel

Expected behaviour

Channel opened.

Actual behaviour

Error: option_channel_type was negotiated but channel_type is missing

Investigation

It seems that lnd is silently not sending the channel type tlv when OpenChannelRequest.CommitmentType isn't set. The lncli default is to not set the channel type.

lnd/rpcserver.go

Line 1995 in c75c3bd

break

@Crypt-iQ
Copy link
Collaborator

Crypt-iQ commented Dec 7, 2021

The above error is an eclair error option_channel_type was negotiated but channel_type is missing right?

@Crypt-iQ Crypt-iQ added channels interop interop with other implementations labels Dec 7, 2021
@joostjager
Copy link
Contributor Author

Yes

@Roasbeef
Copy link
Member

Roasbeef commented Dec 9, 2021

Seems they've changed behavior (in master?) since their last release.

It seems that lnd is silently not sending the channel type tlv when OpenChannelRequest.CommitmentType isn't set.

Thing is, we don't necessarily know if the other side actually supports the feature when a user goes to open a channel type. So we opt to not use explicit funding if the user doesn't select a type manually.

As the spec is written right now, it's technically ok for them to always require it (the "MAY" wording), but there're still some other ambiguous cases, like: we don't set it, but they do (in accept_channel) now we both go to implicit. So it's up to an implementation today if they always want it or not.

edit: ok so we were compatible with the pre feature bit version (their original deployment), but seems not their current master branch (post feature bit)?

@Roasbeef
Copy link
Member

Roasbeef commented Dec 9, 2021

Ok, cleared things up here with some of the other BOLT-ers, we can both ensure that users don't get downgraded, but also maintain compat across all levels. We'll soon have some CI up to run cdecker's old cross-impl tests to make sure this gets caught during the rc process (ideally we only target the last major release, since the master branch can at times be a moving target).

@Roasbeef Roasbeef added this to the v0.14.2 milestone Dec 9, 2021
Roasbeef added a commit to Roasbeef/lnd that referenced this issue Dec 16, 2021
In this commit, we switch to always sending a channel type when we're in
explicit mode. This is compatible with prior versions of lnd as they
won't send a channel type, and we'll just arrive at the same type via
the existing implicit funding.

Fixes lightningnetwork#6067
Roasbeef added a commit to Roasbeef/lnd that referenced this issue Jan 26, 2022
In this commit, we switch to always sending a channel type when we're in
explicit mode. This is compatible with prior versions of lnd as they
won't send a channel type, and we'll just arrive at the same type via
the existing implicit funding.

Fixes lightningnetwork#6067
matheusd pushed a commit to matheusd/dcrlnd that referenced this issue Feb 12, 2024
In this commit, we switch to always sending a channel type when we're in
explicit mode. This is compatible with prior versions of lnd as they
won't send a channel type, and we'll just arrive at the same type via
the existing implicit funding.

Fixes lightningnetwork#6067
matheusd pushed a commit to matheusd/dcrlnd that referenced this issue Feb 22, 2024
In this commit, we switch to always sending a channel type when we're in
explicit mode. This is compatible with prior versions of lnd as they
won't send a channel type, and we'll just arrive at the same type via
the existing implicit funding.

Fixes lightningnetwork#6067
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
channels interop interop with other implementations
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants