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.

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.

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.

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.