-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
[bug]: Unhandled commitment type in channel acceptor request with zero conf channels from CLN #7642
Comments
Yep, we only support zero fee anchors for zero conf channels. Zero fee anchors (as they're much safer) are the future!
We should improve the logging here though. |
I don't really get it though, because I could open up a zero conf channel with the previous version of CLN. Meaning that LND does support these zero conf channels without anchors. Seems like it's just a channel flagging concern, in which case I'll probably have to go back to CLN to tell them to stop sending over those flags? And it was my understanding that LND won't open non-anchor channels but should be accepting them from others like the callouts with LDK specify in the original zero conf channel feature PR. |
@Roasbeef got this comment:
I'm struggling to find where the issue is between the two. You were mentioning zero fee anchors but it sounds like this might be more related to flags? Can you help me understand that? |
Looks like that's in response to this: https://twitter.com/Snyke/status/1659544009037971456?s=20 I believe he is incorrect. LND will happy acknowledge channels with It sounds like it was a bug that CLN was was passing So in order for CLN to open zero conf channels again with LND, then there's a few options:
Between @Roasbeef or @cdecker I'm not sure who will budge here, I don't see any way around this protocol incompatibility between the two implementations. |
So just to clarify the current state of things:
Once again, Also zero conf and scid alias are distinct: you can open a static channel with scid alises np, but not also with zero conf (which also requires scid alias in order to be useable). Returning to @TonyGiorgio's scenario in the OP: it looks like you're having You correctly identified above that we don't explicitly support With all that said, the error you're seeing is a bit further in the chain at: |
Thanks for the run down @Roasbeef. This is helpful in understanding what's going on here. I hear you on anchor channels and I'm excited for them to be more widespread. Definitely not asking to regress that.
We had previously had something like this but have since removed it.
That is correct that we run a channel acceptor to facilitate this response of a zero depth. I appreciate willingness to work with this solution until we're at a fully deployed state of zero fee anchor channels. To make sure I understand, would it be best to open a PR into #7177 or master? |
@morehouse sounds good. I just opened a new PR for this into master. |
@TonyGiorgio @Roasbeef @morehouse - It appears this compatibility issue is fixed in the latest CoreLN Version (https://github.com/ElementsProject/lightning/releases/tag/v23.05.1). See PR (ElementsProject/lightning#6304). We've tested that this does fix the issue and this version of CoreLN is able to open zero conf channels into LND once again. So that fixes our issue. The question now is; what do we do with #7740? I'm in favor of closing it as the superior solution was reached and this subpar solution is no longer necessary. Do we have any objections to that? Thanks! |
I don't think ElementsProject/lightning#6304 is a "superior solution"; it seems more like a hack to maintain CLN's previous (spec noncompliant) behavior when doing zero-conf between CLN and LND. I think the better solution is to make LND accept the specific channel type when it is explicitly negotiated (via That said, CLN is working on zero fee anchors, so probably not a big deal if we just wait for that and don't fix things on the LND side. As all implementations start to support modern channel types, we may even want to reduce the channel types we support (to simplify code and protect users). |
@morehouse Yeah I probably used words improperly there, haha. I was mainly meaning not supporting a less-ideal channel type in LND and instead wait for everyone to support the more preferred channel type. |
@gkrizek based on the comments above, I cleared the milestone and closed this issue. Feel free to reopen if you think otherwise. |
Issue and Steps to Reproduce
Sometime since CLN 12.0, CLN no longer opens zero conf channels to LND.
I have a CLN pinned to that commit and I have one that's on the v23.05rc2.
Both CLN's can open up zero conf channels just fine to LDK and CLN nodes. However, I'm trying to understand what might be the issue on LND's side. Odds are there's some issue on one side or another that I need to get to the bottom of, I have cross posted this to CLN here: ElementsProject/lightning#6208
CLN 12.0
LND v0.16.1 (working):
CLN v23.05rc2
LND (not working):
CLN logs:
The thing that stands out is:
When I look at the LND switch case that handles that, I do not see one that just handles those two channel type features:
lnd/chanacceptor/rpcacceptor.go
Lines 274 to 346 in fdc1ae9
Being just
StaticRemoteKeyRequired
&ScidAliasRequired
.Question for LND:
StaticRemoteKeyRequired
&ScidAliasRequired
?The text was updated successfully, but these errors were encountered: