How to use v1 account for v2 actions?

Support
,
1

For the vote, I would be stuck at this step, since I don’t know how to add my credentials to polkadot.js extension. Ğecko is a non-go for me. Can it be done from Tikka?

Of course, I read them before. You mean that it is to be fixed? How did you guys overcome it?

2

I just added the tech-vote command in gcli (x86_64 build here):

gcli --secret "my mnemonic" tech-vote <hash> <index> <0|1>

I can try to add another method to pass the secret if you don’t have a mnemonic.

1 Like
3

Thanks for the command!
But the mnemonic is from a different format than v1 format.
How did you convert your v1 credentials (mnemonic) to v2 mnemonic?
I’ll try implement it if this feature doesn’t exists yet.

1 Like
4

First you have to look at the account address used in the Technical committee.
If it is your V1 account in V2 address. You can not vote. You must have a v2 account with an english mnemonic in the TC member list. Also, if you have a french mnemonic, Polkadot will not understand it.

You do not need to be a member to vote.
The address for me in the TC is a V2 root account with an english mnemonic. No identity. It is fine.

1 Like
5

Thanks, I see you are all not using your Ğ1 accounts.
I’ll create a new one for ĞDev then.
Then, we will be able to set my address in the Technical Committee and on my node \o/

My issue is that we can’t get v2 seed (English mnemonic) out of v1 credentials.
They are kind of lost, we get a Keypair object in py-substrate-interface.
Where we have the mnemonic from freshly created v2 Keypair.
We can transfer money from our v1 wallets to v2 wallets, but regarding member pubkey, I don’t see how to solve that yet.

6

I added seed support in gcli: (v1 and v2 compatible)

gcli -S seed -s <seedhex> ...

(-s can also be omitted, then the seed will be asked from stdin)

2 Likes
7

Right, allowing to pass sedheex to clients we are developing for Ğ1, as you did in Ğcli. (Un)fortunately, polkadot.js doesn’t support it, so we have to implement all the features in our clients in the meantime in order to be able to use them.

8

The problem is that even Ed25519 is well managed by Substrate, only Sr25519 is available in Polkadotjs app. From there, two options:

  • you choose to keep your identity on your Ed25519 key and use tools compatible with it like gcli
  • you migrate your identity to a Sr25519 key and then use this new key to sign documents

For Ğ1 migration, I think we will have enough tooling to perform all the operation from legacy Ed25519 keys, but for ĞDev, it would be more convenient to migrate your identity because at the development stage, we rely a lot on Polkadotjs app.

I would totally understand your choice to keep Ed25519 keys, but then we would have to implement new features more quickly in gclior in silkaj.

Also keep in mind that both methods (mnemonic / salt+password) are valid to generate both kind of keys.

1 Like