user20835: I'm wondering if it is possible to shut down my node, change my node id, but persist my channels in the Lightning protocol. Is there an inherent limitation to the protocol that prevents this from happening? From looking from BOLT2 it seems like there isn't? 

user81940: I think what you ask is not possible when we want to follow the protocol for the following reasoning: (sorry I am a bit weak on BOLT 07)
If you look at BOLT 07 and the channel announcement messages you will see that you have to sign off channels with the bitcoin_keys that belong to the node_ids of the funding pupkey.
If you change your node_id you would not only have a different funding pubkey but also you would have to (ex)change both signatures for your channel_announcment-message. Both signatures because you changed data in the channel announcement message so your channel partners would have to sign off too. Since I don't see how the protocol could handle such an update (the change of the funding pubkey as well as exchanging new signatures) I don't see how you could announce that channel.
Of course you need to announce the channel if you want to let know people that this channel belongs to your new node_id. A hacky solution might be to make this channel private but still your channel partner would probably not out of the box support this.
In case this feature is needed I can imagine how a hack with leaving the node_id but making the channel private and use the upcoming Rendez-vous routing might work but that would also require patching your lightning node.

user88614: BOLT#7 outlines in the rules for receiving channel_announcement messages, that any previously known channel with differing node_ids, should result in the blacklisting of all associated nodes for both the current message and the previously known channel.

if it has previously received a valid channel_announcement, for the same transaction, in the same block, but for a different node_id_1 or node_id_2:

SHOULD blacklist the previous message's node_id_1 and node_id_2, as well as this node_id_1 and node_id_2 AND forget any channels connected to them.


EDIT:
I suppose a potential way around the above would be to wait over 2 weeks and publish no updates. Since the software will generally forget about nodes or channels which they have not received an update for in two weeks, then when you broadcast a node_announcement for a previous channel under a new node_id, then other network participants will just see it as a new channel.
This would need negotiating with the channel partner to not close it and to re-establish it under a new node_id, which there is currently no means of doing so in the existing spec.

20835: <p>I'm wondering if it is possible to shut down my node, change my node id, but persist my channels in the Lightning protocol. Is there an inherent limitation to the protocol that prevents this from happening? From looking from BOLT2 it seems like there isn't? </p>
 81940: <p>I think what you ask <strong>is not possible</strong> when we want to follow the protocol for the following reasoning: (sorry I am a bit weak on BOLT 07)</p>

<p>If you look at <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#the-channel_announcement-message" rel="nofollow noreferrer">BOLT 07 and the channel announcement messages</a> you will see that you have to sign off channels with the <code>bitcoin_keys</code> that belong to the <code>node_ids</code> of the <code>funding pupkey</code>.</p>

<p>If you change your <code>node_id</code> you would not only have a different <code>funding pubkey</code> but also you would have to (ex)change both signatures for your <code>channel_announcment-message</code>. Both signatures because you changed data in the channel announcement message so your channel partners would have to sign off too. Since I don't see how the protocol could handle such an update (the change of the <code>funding pubkey</code> as well as exchanging new signatures) I don't see how you could announce that channel.</p>

<p>Of course you need to announce the channel if you want to let know people that this channel belongs to your new <code>node_id</code>. A hacky solution might be to make this channel private but still your channel partner would probably not out of the box support this.</p>

<p>In case this feature is needed I can imagine how a hack with leaving the node_id but making the channel private and use the upcoming Rendez-vous routing might work but that would also require patching your lightning node.</p>
 88614: <p>BOLT#7 outlines in the rules for receiving <code>channel_announcement</code> messages, that any previously known channel with differing node_ids, should result in the blacklisting of all associated nodes for both the current message and the previously known channel.</p>
<blockquote>
<p>if it has previously received a valid channel_announcement, for the same transaction, in the same block, but for a different node_id_1 or node_id_2:</p>
<ul>
<li>SHOULD blacklist the previous message's node_id_1 and node_id_2, as well as this node_id_1 and node_id_2 AND forget any channels connected to them.</li>
</ul>
</blockquote>
<p>EDIT:</p>
<p>I suppose a potential way around the above would be to wait over 2 weeks and publish no updates. Since the software will generally forget about nodes or channels which they have not received an update for in two weeks, then when you broadcast a <code>node_announcement</code> for a previous channel under a new <code>node_id</code>, then other network participants will just see it as a new channel.</p>
<p>This would need negotiating with the channel partner to not close it and to re-establish it under a new node_id, which there is currently no means of doing so in the existing spec.</p>
