By default, Parity Vault uses the chain in derivation paths: If you make an account on polkadot, then you’ll have a derivation path like //polkadot//... If you make an account on AssetHub from the same secret words, then you’ll have a derivation path like //statemint//...
This means once relay chain accounts are migrated to AssetHub then if users simply import metadata for assethub and press the button to generate assethub accounts, then they’ll have a different public-secret key pair, without any affiliated balance, even after the migration.
Instead, migrated relay chain account holders should import metadata for assethub and when they say to generate a key they must manually edit the suggested //statemint//.. derivation path to //polkadot//... This will recreate the exact same public-secret key pair used by the realy chain account.
This must be done for each of your relay chain accounts.
Thanks for pointing out this potential headache with the AssetHub migration for Parity Vault users.
You nailed it – the way Vault handles derivation paths (creating different accounts per network) could really confuse people, causing them to not find their funds if they’re not careful with the manual derivation path changes.
It’s a tricky situation because Vault’s design was aiming for better security, but now we’ve got this UX challenge.
I’m curious to hear your thoughts on how you think this UX experience could be best addressed. What would be your approach to guide users through this process in the most user-friendly and error-proof way possible, minimizing the risk of funds being inaccessible post-migration?
Vault has good reasons for doing this besides reducing the privacy dumpster fire: If nonces advance sequentially, then you risk replay attacks when using the same key across multiple chains. We’ll maybe have some nice replay attacks in ETH roll up land.
We hopefully use non-sequential nonces, which mitigates this, but if not then we do have some problems for non-Vault users too. Also sometimes Vault’s trick could be by project or app though, not by actual chain, so then if a project or app runs across 10 parachains then they all use the same keys.
I think UTXO coins like BTC typically do different keys for different UTXOs, unless maybe they use soft derivation paths, which provide nothing, so not exactly a new idea. Also, we really need stronger privacy measures, but that’s a whole other world of complexity, like see Zcash under the hood.
Afaik Vault sees both the public key ands the chain id when it gives you this error, right?
I suppose some future Vault 8 could recognize that it requestes key on a different chain from the requested one, so they it could simply ask the user if they wanted to enable that key on that chain. This maybe the simplest process, although it’s useless for old Vault users.
AssetHub could be white listed for //polkadot/ keys too, although in general we might worry about white listing smart contract chains.
A replay-attack for a signed-extrinsic created on a different chain ain’t really feasible as there are many signed-extensions that wouldn’t match on a different chain: the most obvious one being the CheckGenesisHash signed-extension.
The only replay-attack that I think it’s feasible is if an account creates an immortal transaction, then that account goes bellow their existential deposit, and then later on that same account receives funds again… If all those things happened inside the same chain, without a runtime-upgrade in between, then the replay attack could happen, yes. The reason why a runtime-upgrade would invalidate previous transactions is the CheckSpecVersion signed-extension.
I really wish that there was a feasible way to have non-sequential nonces… However, I’m afraid that as of today that’s not really an option for Polkadot-SDK chains.
