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?
asked Jan 29, 2019 at 21:00
-
Not on the transaction level (Bolt3) either.– James C.Commented Jan 29, 2019 at 21:25
Add a comment
|
2 Answers
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.
-
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. Commented Jan 30, 2019 at 0:43
-
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 HCommented Jan 30, 2019 at 1:05
-
@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? Commented Jan 30, 2019 at 11:45
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.
