Lightning nodeid() returns a different value for each wallet seed restore

[rp-li]

Expected behaviour:
When regenerating the same wallet from seed multiple times, the lightning node ID (output of nodeid()) should remain the same. AFAIK this makes it possible to restore lightning channels once a wallet is deleted. This is the intended behaviour in the ACINQ Eclair wallet (@t-bast).

Actual behaviour:
Generating multiple bech32 wallets from the same BIP39 seed produces different nodeid(), even on the same device.

[SomberNight]

see #5978

[ecdsa]

It is our long-term goal to be able to restore channels from seed, but that it not going to happen soon. The lightning-dev mailing list has recent posts that suggest how to do that, but those ideas are far from implementation, and very far from standardization across LN implementations. Expect these things to take a year at least. In the meantime, the expected behaviour of Electrum is to generate a new nodeID everytime you restore, so that your wallet does not conflict with other instances.

What ACINQ/EClair did is a proprietary solution, that only works with their server. We do not want to do that, because we want users to be able to open channels with other nodes than us. We do not want to be (or to have) a single point of failure.

[t-bast]

What ACINQ/EClair did is a proprietary solution, that only works with their server

That only concerns restoring off-chain channels with HTLCs.

But having a deterministic node_id from a seed is important to allow users to get their previous channels force-closed and recover their main output (especially coupled with static_remotekey). If you don't offer deterministic node_ids, the only solution for users who lose their phone or uninstall the app is to remember who they had channels with, contact them and ask them nicely to close the channel? That doesn't look very realistic...

[t-bast]

Also node that our encrypted channels backup solution can work with any node that implements it, if there is interest, not only ours.

[ecdsa]

@t-bast not sure what you mean.. It seems to me that if your node is private (and that is the case of Phoenix and Electrum), then you do need to remember who you had a channel with, regardless of whether your node_id is deterministic. I believe Phoenix solves that by only connecting to the ACINQ node only.

[t-bast]

Yes you need to remember that, but at least you don't need the other party's cooperation to force-close your channel: just reconnect to them and option_dataloss_protect will get the other node to close the channel.

If you have no way of getting the private key of your previous node_id, your only solution is to contact the other peer (if even possible) and ask them to force-close the channel (and you need to prove to them that you are the owner, which is painful without the node_id's private key).

[t-bast]

@rp-li had to contact us via gitter about a channel he opened with us, then we had to come up with a challenge to get him to prove his identity without his node_id's private key, then we had to force-close his channel manually...I really don't want to have to do that regularly in the future :/

[t-bast]

I understand the argument of preventing users from using the same node_id on multiple devices though, that can be a disaster as well, and it's hard to explain to users (especially in your case, because it's completely ok to use the same seed on multiple devices for on-chain stuff).

[ecdsa]

oh I see, by "contact them" you meant some kind of human interaction. Indeed, that is not serious :-)

Seriously, Electrum has static channel backups because it needs to remember who you have a channel with. So, I was using the word "remember" with the meaning: "the user has a backup of", not "the user remembers". Now, if you need a backup of who you had a channel with (and that is our case), it is not more expensive to add your own node_id to the backup, and that is what we do, because it prevents conflicts between multiple instances of your wallet.

I believe Phoenix does not need a backup of who it had a channel with, because it only allows to open channels with ACINQ. Should Phoenix allow to open channels with other nodes, it too would need users to save backups.

[t-bast]

Ok that makes sense, then we really must ensure users don't lose these static channel backups (otherwise too bad for them). Then you're probably right that we should keep exploring the ideas that have been floating around on the ML recently, and it will take time!

[ecdsa]

@t-bast check out the december posts by Lloyd Fournier on the lightning-dev mailing list