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

ChannelAuthProof for own channels is missing after running dropchannelgraph #48

Open
silenzara opened this issue Sep 22, 2022 · 11 comments

Comments

@silenzara
Copy link

I used dropchannelgraph with the intention to fix missing channel information that was introduced due to running with routing.assumechanvalid=true when I started using my node for the first time.

The command was successful and my node started synching the graph to a state that had all channel information like I wanted to. So that's awesome.

I did however notice that all my channels were missing when I ran lncli getnodeinfo <my_pubkey> --include_channels. The channels were present when I ran lncli listchannels or when I ran getnodeinfo with my peer's pubkey however.

At this point I asked for help on the LND slack and guggero responded. The issue has to do with the ChannelAuthProof not existing for my own channels. Causing LND to interpret my channels as unannounced and not listing them.

Normally, the ChannelAuthProof is created before the channel is publicly announced and without it the channel cannot be announced because the "proof" is needed by other nodes to verify that the channel is legitimate.

Luckily for me the proof is remembered by my peers that I share the channel with so they can do the broadcasting of the channel. But the situation is not ideal for sure.

So in part this github issue is to document the behavior of dropchannelgraph and also write a bit about ChannelAuthProof since google did not provide any information about it.

The other reason is to make a feature request to dropchannelgraph that will create the proof after adding the nodes edges. Like you (guggero) already said on slack it is a bit tricky since you need to pass the seed to sign the proofs.

@yo-mr-white
Copy link

Hi @silenzara ,
are there any negative consequences with you node not having the channels information in getnodeinfo command (node gossip)? For example - do you know if something important is using the data from there?

And also - could you please describe the procedure to force peers to do the broadcasting of the channels?

Thank you!

@silenzara
Copy link
Author

@Heisenberg-CZE I don't notice anything different with regards to gossip; logs are normal like it's supposed to be.

I would not know how to force a peer to broadcast the channel. I actually think it's not necessary to force broadcast anything. Once a channel is published/broadcasted it will be known to the network and it will be propagated to new nodes via historical graph sync.

So right now everything is OK, but I am worried that with a future lnd update or new BOLT I will need the auth proofs. Also, as a precaution, I recreated some of my important channels to be sure they work correctly.

Definitely would not recommend running this way.

@yo-mr-white
Copy link

Thank you. It's definitely not something I want to do but I'm afraid I'm going to have to as my gossip graph is corrupted and only sees +- half of the nodes/channels.

Just to be clear:

  1. If you run lncli getnodeinfo <your_pubkey> --include_channels there are no channels, right?
  2. If you run lncli describegraph | jq .edges | grep <your_pubkey> | wc -l does the number matches your channel count? Are your own channels in your graph?
  3. When you change your fees etc., are the channel_updates propagated through the network? For example do you see the changes in Amboss.space etc.?

Thank you in advance for your time!

@silenzara
Copy link
Author

silenzara commented Nov 17, 2022

  1. I only see 95 of my 130 channels right now. But right after dropping my graph it showed 0 indeed.

  2. Correct, it only shows 95 channels just like with 1). If I run lncli describegraph with --include_unannounced then it shows all of my 130 channels.

  3. Never had any issues with updating fees on those channels. When I first noticed things where not like they are supposed to be I monitored amboss.space closely to see if my fees were updated correctly and that was the case. Till this day I never noticed anything out of the ordinary.

Related to 3: When I dropped the graph I did have issues with policies missing from my channels. Basically everything was set the the defaults. I'm not sure if it were some lnd internal defaults or defaults from my config. I think some internal defaults because everything was 0ppm (also my juicy sinks that were drained pretty quickly before I could react). So if you decide to drop the graph, be prepared to do some ninja policy updates. I was using charge-lnd at the time and with that tool I had no success because charge-lnd could not find many of my channels. It was pretty hectic..

@yo-mr-white
Copy link

Thank you once again for your information. I will let you know if there will be something unusual or different from your experience.

@Gridflare
Copy link

I'm confirming that my node's channels are also missing from the graph after using dropchannelgraph and re-syncing. I've tried --fix_only, and it complains that the channels are already there. A fix appears to be referenced here lightningnetwork/lnd#6571 (comment) but I have not found it in the chantools documentation.

I'll update in a few days about how many of my channels recover by themselves.

@Gridflare
Copy link

lncli getnodeinfo 02e2bf9e87c7ba0ea046882d9b3301ca9a3b049aa920dccbd836c4008eac32d4e5 --include_channels
is still not returning a list of my channels after resyncing for a while.
I noticed that some of my channels weren't responding to policy updates from my scripts, but did work with thunderhub.

@silenzara
Copy link
Author

@Gridflare the reason you're not seeing the channels in getnodeinfo is because your node is missing a piece of information (the auth proof). Without the auth proof for the channel that channel will be interpreted as a private/unannounced channel even though it's not. The issue/comment you are referring to is only about the channels missing from the graph, not the auth proofs of those channels, that's a different (and open) issue.

If you run lncli describegraph | jq .edges | grep <your_pubkey> | wc -l you will see the missing channels. AFAIK the only practical way to fix it right now is to recreate (close and reopen) the channels.

I ran my node for ~six months with some channel auth proofs missing and I didn't notice any negative effects. Eventually I did recreate all the channels that were missing the proof and I didn't notice any difference (except that I could rule out the missing auth proof as a reason for some other issues I was having).

@Gridflare
Copy link

This command returns 0, my channels are not in my graph at all.
I was afraid that redoing all of my channels was the only solution.

@silenzara
Copy link
Author

Sorry, the correct command is lncli describegraph --include_unannounced | jq .edges | grep <your_pubkey> | wc -l

The --include_unannounced is important in this case. Does it still return 0 channels with that parameter added?

@Gridflare
Copy link

That does work, although it includes my private channels with my public ones, which is a little bit annoying for graph analysis.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants