1

I'm writing a dApp where I need to create a "native" (not beacon) wallet so it can perform some automatic operations.

Occurs that, with the same mnemonic words used to create a wallet in Kukai, I'm getting different public key hashes when creating wallets with Taquito "InMemorySigner".

I am using defaults from Taquito "InMemorySigner", i.e., curve = 'ed25519' and derivationPath "44'/1729'/0'/0'". I imagine Kukai must be using something different.

But Temple wallet mnemonics work on Taquito "InMemorySigner" (giving same public hashes).

What are the best practices here? I want the user to import a wallet, regardless where it came from.

2 Answers 2

1

Could you help confirm if Temple wallet returns the same pkh as Kukai?

In advanced options in Kukai, there is the ability to select HD wallet or legacy wallet.

Could you confirm that the key you are looking for is a tz1...?

I have just checked a test mnemonic that I have on all 3 Kukai, Temple, InMemorySigner.fromMnemonic and was able to recreate the pkh in all 3

If you are trying to get the same curve and derivation path account, then there should be no problem with the InMemorySigner.fromMnemonic to recreate it.

I found that some mnemonics are not encodable for one (possibly more, but I have yet to see any) of the curve derivation requirements.

Could you share some code of where the result is going wrong to understand better what may be happening?

Post-added code, for illustrative purposes:

                const params =
                {
                    mnemonic: "[my 24 word mnemonic]",
                    password: "[myPassphrase]"
                }            

                const TezosNative = new TezosToolkit(this.configuredRpcProvider);
                const signer = InMemorySigner.fromMnemonic(params);
                TezosNative.setSignerProvider(signer);
                await TezosNative.signer.publicKeyHash()
                .then((publicKeyHash) => {
                    console.log(publicKeyHash);
                });

This returns me : tz1UYo2sTAE5pEs6SeCT9wg3FrxcxDcoHc1k
Kukai and Temple returns me : tz1W4Vs3VEw87yVMHY9QTH738NDWYNTqmwGR

With same 24 mnemonic words and passphrase.

12
  • 1
    There is a chance that the part of code Kukai uses for interpreting mnemonics are parsing it differently to what we use in Taquito. I am not entirely sure what library Kukai uses to do so, or if they have any in-house solutions for that. But in Taquito, we rely on some 3rd party packages that we've tested against the octez-client. Apr 14 at 22:35
  • 1
    Looking at Kukais code there is a difference of how the seed is generated by using @tezos-crypto-tools/crypto-utils and ours using bip39 this is possibly amendable for consistency however it would take more digging to understand the differences between the two packages and what tezos would like to have as a consistent rule of mnemonic to seed
    – Zainen
    Apr 14 at 22:50
  • 1
    Could you for a sanity check test the InMemorySigner.fromMnemonic the password = '' ?
    – Zainen
    Apr 15 at 1:11
  • 1
    I found out that, if I pass an empty string in the "password" field, it works, giving me the same pkh as Kukai and Temple: tz1W4Vs3VEw87yVMHY9QTH738NDWYNTqmwGR. Could Taquito InMemorySigner be ignoring passphrase? Apr 15 at 1:17
  • 1
    its the other way around I believe. the password is not used since its impossible to recover your account or help to recover it by the wallet provider
    – Zainen
    Apr 15 at 1:29
0

I'm starting to believe that there were some kind of error in the moment that Kukai generated the wallet and it went without the passphrase. I will create other sets of mnemonic words + passphrases to check it out.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.