Lightning: Clarification: Waiting for their announcement signatures. What does it actually mean?

[CluelessFool]

This is more of an information request because I don't understand something.

Most of my channels have the state & status of:

          "state": "CHANNELD_NORMAL",
          "status": [
            "CHANNELD_NORMAL:Reconnected, and reestablished.",
            "CHANNELD_NORMAL:Funding transaction locked. Waiting for their announcement signatures."
          ],

What I am expecting to see is that the channel has been announced, something like:

          "state": "CHANNELD_NORMAL",
          "status": [
            "CHANNELD_NORMAL:Reconnected, and reestablished.",
            "CHANNELD_NORMAL:Funding transaction locked. Channel announced."
          ],

From other issues like https://github.com/ElementsProject/lightning/issues/1174 I gather that the channel, while usable by my node, is unusable for routing others because, as it literally says, lightningd does not yet have the other nodes signatures yet.

I also see in a lot of other issues where people have posted a channel they have channels in the same state.

So, my questions are:

• What is the root cause of this?

• Does the message "state": "CHANNELD_NORMAL" mean they are operating correctly despite the status message?

• What if anything I should do about these channels?

• If I want them to be used for routing should I close them because they are not functioning in that capacity?

As a general comment, having multiple status fiels is a bit confusing, it might be better to have a single status message that progresses all the way from "INITALIZING" all the way to "FULLY_OPERATIONAL".

Issue and Steps to Reproduce

Open a channel, most channels in my experience end up with this message.

getinfo output

{
  "id": "------------------------------------------------------------------------------------",
  "alias": "-----------",
  "color": "---------------------",
  "address": [
    {
      "type": "ipv4",
      "address": "----------------",
      "port": 9735
    }
  ],
  "binding": [
    {
      "type": "ipv4",
      "address": "----------------",
      "port": 9735
    }
  ],
  "version": "v0.6-203-g5230302",
  "blockheight": 534445,
  "network": "bitcoin"
}

P.S. Thanks for all the brilliant stuff you guys are doing for us (for free) I for one really appreciate it.

[cdecker]

For a channel to be publicly announced we need both parties to agree on sharing the channel details. This is done by requiring the channel_announcement message to be signed by both parties, with their node ID and the bitcoin pubkey that is used for the funding transaction. Once the channel depth is reached they will spontaneously send the required signatures for the announcement to the other side, and wait for the other side to also send theirs.

If the endpoints have different confirmation depth requirements it can happen that one side already sends theirs, but the other side isn't ready to send yet. Furthermore, if the connection gets dropped this may be the case for a prolonged period, since we need an underlying connection to be able to exchange signatures in the first place. On reconnect the nodes should exchange signatures and continue normally, however some implementations seem not to do that, leaving the channel unannounced despite being confirmed and being connected.

The channel is usable, but simply cannot be announced yet to the rest of the world.

[Illidanek]

I have the same issue with multiple channels. What should I do (or the other node do) to "force" send the signatures? All these channels have well over a thousand confirmations.

I tried restarting my node but that just seemed to make things worse.

[cdecker]

This seems to be an issue with lnd not adhering to the protocol specification by sending the announcement at a weird point in time, or us not processing it because we didn't expect it here. I was able to fix it a few times by restarting my node, causing them to send again.

[mloop1]

Could you guys explain what does it mean to "reach the channel depth"?

[cdecker]

So when setting up a channel, there are 2 separate confirmation heights that are of interest:

• The two endpoints decide how many confirmations they require before they consider the channel to be operational, i.e., it can't be reorged with high probability, and they are happy to start updating the channel state by performing transfers. This is communicated with the fungind_locked message, after which we can start adding and removing HTLCs for example.
• The network decides on a number of confirmations that are needed before it'll accept channel_announcements and channel_updates for a given channel. This is signaled by exchanging the announcement_signatures message.

The former is currently anywhere between 2 and 6 confirmations if I'm mistaken (lnd requires more confirmations for higher value channels for example), while the latter is at 6 confirmations for the Bitcoin Lightning network.

Announcement signatures are only exchanged when both funding_locked messages have been exchanged as well as the announcement depth of 6 blocks has been reached.

[mloop1]

thanks, this helps

[mloop1]

I have a channell that used to be in status "CHANNELD_NORMAL:Funding transaction locked. Channel announced." and is now in status "CHANNELD_NORMAL:Funding transaction locked. Waiting for their announcement signatures."
Peer id: 03fce165537aea120bffe8505876b44d5119354f825b3eac329b761fc5636bf334

Is there anything we can do to fix it?
I tried to restart the lightning daemon, but didn't help.

[SimonVrouwe]

Same problem here and restarting c-lightning actually makes it worse. First I lost the announcement sigs of 2 of my 3 channels because of a crash of my node so these 2 hang in
waiting for their announcement signatures
Then added a new channel, which made it to channel announced
but after a restart that one now also in waiting for their announcement signatures.
So I guess we don't store announcement_signature persistent?

@cdecker Can't we just store the announcement_signature in the db and use that as a fall back ?

BOLT#7 says:

A node:
...
    upon reconnection (once the above timing requirements have been met):
        MUST respond to the first announcement_signatures message with its own announcement_signatures message.

I assume here that the word _first_ should be interpreted as _first of two_? (and not as _first ever_)

[cdecker]

I assume here that the word _first_ should be interpreted as _first of two_? (and not as _first ever_)

First as in don't just ping-pong indefinitely (I see your announcement, I reply, to which you reply, to which I reply, ...)

@cdecker Can't we just store the announcement_signature in the db and use that as a fall back ?

We could probably do that, I'll add a feature request to track that

[mloop1]

thanks, I think making sure that c-lightning is compatible with other impls (when makes sense) is going to be more and more critical.

[cdecker]

thanks, I think making sure that c-lightning is compatible with other impls (when makes sense) is going to be more and more critical.

Well, that is certainly our goal, but I think it is worth pointing out that this kind of thing is working around quirks in other implementations, since we are in sync with the spec.