I just found some information on how wallets and key phrases work in the docs and I’m investigating now. I’m going to do some experimentation and then I might have some more stuff for you to try. Looks promising, but don’t get your hopes up yet.
Interestingly there are like an unlimited number of different account addresses that you can derive from the same seed phrase. The good news is, @brkcmn, if you truly do have the seed phrase you used for your lost wallet, and you haven’t gotten any of the words wrong, then you should be able to recover the account if we can figure out the derivation path used to create your wallet addresss.
I’ve got a couple more questions.
When trying to restore your wallet using the key phrase, did you try the deprecated derivation path in the dropdown? ( you only showed screenshots of the non-deprecated options ):
Also, have you created lots of different accounts in your wallet ( more than 10 )? For instance, using the “Add Account” button:
If your lost account was, for instance the 11th or later account that you created using the “Add Account” button, then it would not pop up in the list when trying to restore your wallet and we can restore it using the Solana commandline.
Also, @dexen , I discovered the reason for the weirdness that you and I noticed when trying to restore your key! Apparently the seed phrase ( and password, if you specified one when creating the account ) are fully sufficient to restore your wallet.
So when running the command solana-keygen pubkey prompt://, the reason that it gave us a different public key than the one that it showed when creating the wallet is that the key shown when creating the wallet is the “master” public key, and typically isn’t used for transactions.
Instead of using the master public key for transactions, it seems like the general practice is to use a derived public key which is useful for privacy’s sake. Essentially you can have any number of keypairs generated from your seed phrase, and each one has a different derivation path. When using the prompt:// syntax in the CLI, it defaults to using the derived key with a derivation path of m/44'/501'/0'/0'.
This is the address that most web wallets will use I think, which explains the difference from the CLI address when creating the keypair. If you wanted to use a different derived address than the default, in the CLI you can specify a different derivation path by using this syntax: prompt://?full-path=m/44'/501'/1'/0'.
This lets you control any number of different accounts, without having to remember/store different seed phrases!
This is actually very cool, it’s just rather confusing.
What exactly are those numbers after m/? That also means,
Storing the seed phrase (and optionally the passphrase) isn’t enough. You need to also store/remember those weirdo parameters, or use a sequential scheme. Maybe this is actually standard practice, but I haven’t seen absolutely anything in the docs about this.
There seems to be no way to derive all the keypairs you’ve used based on a given seed phrase. You need to store/remember them/use a sequence and remember its end. And not run over 44?
Yes the sequential scheme is to increment the 3rd number from the left, starting at zero and going up. It can go to a very high number, at least 99999999, but that was just as high as I tested on the CLI by trial and error.
This scheme is defined by the BIP-0044 proposal and is implemented in the Sollet wallet, when you use the “Add Account” button.
Again, the 44 isn’t actually a limit, it can go very high, but there isn’t a specific way to know all of the accounts that you’ve generated from a seed phrase. As far as anything can tell cryptographically, they are all totally unrelated accounts ( which is important for privacy ) and you just happen to be able to get their public and private keys by deriving them from your seed phrase.
The only way to know which derivations you’ve actually used is to just go one by one up the list in sequence and check the balances. By the convention in BIP-0044, wallets are supposed to automatically discover all accounts derived from a wallet by going up that sequence starting at zero and assuming that there are no more wallets once the reach 20 derived addresses in a row that all have a balance of 0.