### What are "Zombie" channels and why do they matter?
A zombie channel can be defined as a channel in which your channel partner has been inactive for so long, that you do not expect them come back online in the future.
This could be because your channel partner has lost access to their or has permanently shut down that node.
As such, a zombie channel is technically still an open channel, but cannot be used to route payments.
Zombie channels offer no benefit to the user but have several downsides:
* If you lose access to your own node and restore it with only your private key, you will lose access to funds in open zombie channels
* If you lose access to your own node and restore it with your private key and channel backups, you will not be able to contact your channel partner to cooperatively close the channel and may also lose the funds
* Public zombie channels are a burden on the network, as information about them is communicated to the rest of the network, but they cannot be used to route payments
Identifying zombie channels is a challenge as it is not always clear if the channel partner is permanently offline.
A partner node that is offline for a long period may eventually return online in the future.
However, once a zombie channel is identified, it is recommended to close them and a force close is generally required.
#### How does a peer announce a new channel to the network?
Let's assume that Alice and Bob have just opened a channel together.
How do they let the rest of the network know, so that the channel can be used for forwarding payments?
Well firstly, they don't need to.
Alice and Bob can choose not to announce the channel and simply use it to transfer bitcoin between each other.
In this case, they won't earn any fees for forwarding payments.
However, assuming they do want the channel to be public, they will have marked the channel as public when they initially agreed to open it.
First, they'll have to wait until the funding transaction is confirmed (usually six confirmations).
Once it's confirmed, Alice's and Bob's nodes will now use the `channel_announcement` message to let the rest of the network know the good news.
This announcement message contains some important information:
* *Channel ID*: a short description of the channel that tells users which outputs in which transaction in which Bitcoin block were used to fund the channel
* *Signatures from Alice and Bob*: Remember that the channel funds are locked in a 2-of-2 multisignature address, for which Alice and Bob each hold one of the two keys.
Alice and Bob will each sign from their key, proving that their nodes control the funds in the channel.
They will then send this `channel_announcement` message to each of their peers.
Note that while the `channel_announcement` message makes their peers aware of their channel, their peers won't yet be able to use the channel for forwarding payments.
First, Alice or Bob will have to communicate other information, such as their fee policy, which we will discuss below.
But first, how do their peers verify that the channel announcement is legitimate?
#### Verifying the channel
Let's assume Wei receives this announcement from Bob.
How does he know that this is a real channel, and why should he even bother to check it?
Well, verifying a channel is pretty important.
If Wei tries to forward any payments through a channel that doesn't exist, his payments are going to fail.
Even if the channel does exist, Wei still needs assurances that Bob and Alice actually control the funds inside of it.
Alice and Bob could potentially dupe him by claiming ownership of a channel that actually belongs to someone else.
Secondly, Wei will verify the signatures in the channel announcement message and confirm that the two nodes who signed the channel announcement are actually Alice and Bob.
