<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>

CC BY-SA 4.0
2019-01-30T00:43:08.973Z
Your suggestion to wait for ~2 weeks and forgetting does not seem to follow the protocol. I guess if you are offline for such a long time most channel partner will do a force close of the channel.
Rene Pickhardt
CC BY-SA 4.0
2019-01-30T01:05:20.710Z
Yeah, the idea is a hack to get around the blacklisting. You won't be able to do it with existing implementations, but you might be able to do it with modified software and cooperation from the channel's counterparty. The issue would be whether other implementations do forget after two weeks, which is only a recommendation.
Mark H
CC BY-SA 4.0
2019-01-30T11:45:52.313Z
@RenePickhardt It seems like it is a "implementation detail" that most channel partners will force close the channel. I.e. the protocol _allows_ you change your node id, but in practice it is very hard to do due to current implementations. If I were to write a lightning client I could circumvent this, correct? If we are thinking about this from adversarial perspective, can you do anything with this fact?
Chris Stewart
CC BY-SA 4.0
2019-01-29T23:42:48.350Z
2019-01-30T00:23:49.253Z
2020-06-16T11:10:03.350Z
Mark H
<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>

CC BY-SA 4.0
2019-01-29T23:05:46.320Z
2019-01-29T23:05:46.320Z
Rene Pickhardt
<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>

CC BY-SA 4.0
2019-01-29T21:25:11.753Z
Not on the transaction level (Bolt3) either.
James C.
<lightning-network><lightning-routing><lightning-rfc>
Are channel ids inherently linked to node ids in the Lightning protocol?
Chris Stewart
# Are channel ids inherently linked to node ids in the Lightning protocol?

(Asked by: username_0 on 2019-01-29)

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?

**Tags:** lightning-network, lightning-routing, lightning-rfc

> **Comments:**
> **username_1**: Not on the transaction level (Bolt3) either.  

---

## 2 answers

### Answer by username_2 on 2019-01-29. Score: 2 | Accepted answer

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.

> **Comments:**
> **username_3**: Your suggestion to wait for ~2 weeks and forgetting does not seem to follow the protocol. I guess if you are offline for such a long time most channel partner will do a force close of the channel.  
> **username_2**: Yeah, the idea is a hack to get around the blacklisting. You won't be able to do it with existing implementations, but you might be able to do it with modified software and cooperation from the channel's counterparty. The issue would be whether other implementations do forget after two weeks, which is only a recommendation.  
> **username_0**: @username_3 It seems like it is a "implementation detail" that most channel partners will force close the channel. I.e. the protocol _allows_ you change your node id, but in practice it is very hard to do due to current implementations. If I were to write a lightning client I could circumvent this, correct? If we are thinking about this from adversarial perspective, can you do anything with this fact?  

---

### Answer by username_3 on 2019-01-29. Score: 1

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](https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#the-channel_announcement-message) 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.


---

