Restoring a wallet from seed does not restore the domain names

[gits7r]

If try to restore a wallet from seed, and you have a domain name registered, you go to manage domain names, you see one transaction with Registration Pending but it does not know the domain name, and when you click configure a bug pop-up comes:

Traceback (most recent call last): File "/home/ss/electrum-nmc/electrum_nmc/electrum/gui/qt/unolist.py", line 197, in menu.addAction(("Configure"), lambda: self.configure_selected_item()) File "/home/ss/electrum-nmc/electrum_nmc/electrum/gui/qt/uno_list.py", line 292, in configure_selected_item show_configure_name(identifier, initial_value, self.parent, False) File "/home/ss/electrum-nmc/electrum_nmc/electrum/gui/qt/configure_name_dialog.py", line 49, in show_configure_name d = ConfigureNameDialog(identifier, value, parent, is_new) File "/home/ss/electrum-nmc/electrum_nmc/electrum/gui/qt/configure_name_dialog.py", line 72, in init formatted_name = format_name_identifier(identifier) File "/home/ss/electrum-nmc/electrum_nmc/electrum/names.py", line 203, in format_name_identifier identifier = identifier_bytes.decode("ascii") AttributeError: 'NoneType' object has no attribute 'decode'

[JeremyRand]

@gits7r At the time the wallet was restored from the seed, was the name_firstupdate for the relevant name already broadcasted? If so, was it mined already? If name_firstupdate wasn't broadcasted already, then I don't think there's anything we can do, since the seed only lets us derive the private keys, which isn't enough to reconstruct the name (both the name identifier and the name_new salt are needed for that). But, in such a scenario, it's not really a disaster, since the name can be registered again (the user just has to pay the registration fee again).

The exception when you try to configure a name_new (I assume it's a name_new output?) is a known bug, but it looks like I neglected to create an issue for it. I'll add one shortly.

[gits7r]

Yes, I confirm this occurs before name_firstupdate is sent.

So basically if you try to restore from seed your wallet before the domain names finish to register, (after you send name_new but before name_firstupdate) you cannot restore them any more, and you will be stuck with N names pending registration forever.

Why can't we make the salt encrypted with the public key of a an address so we can decrypt it at restore point?

[JeremyRand]

Why can't we make the salt encrypted with the public key of a an address so we can decrypt it at restore point?

@gits7r The most straightforward approach to this that I can think of would be to derive the salt deterministically via the HD mechanism (i.e. as a derivation path), but I think this would result in future salts being predictable by anyone who has your master public key. Is there some other way to do this that you're suggesting?

[gits7r]

Yes, why master public key? Why not derive the salt by hashing the master private key? In case someone has your master private key, having the salts predictable is the least of the problem. This will not work of course for watch only wallets (only the registered names will appear there).

Or at least make it possible to remove the 'pending names' for which we lost the salt and will never be registered.

[gits7r]

Closing this in favor of #266 to treat just the leftover separately.