Hi could you help me with 2 questions?

[jaylinlucero]

1) add generating addresses of the NIMIQ coin from a mnemonic phrase The coin has this specification "id": "nimiq", "name": "Nimiq", "coinId": 242, "symbol": "NIM", "decimals": 5, "Path component (coin_type')":"0x800000f2" "blockchain": "Nimiq", "derivation": "path": "m/44'/242'/0'/0'" "curve": "ed25519", "publicKeyType": "ed25519"

coin addresses start with NQ

2) help with generating an Ontology address for the Exodus wallet for mnemonic, everything I do gives the wrong address...

Help with these scripts! Thank you very much in advance!

[ebellocchia]

1. Ok, I just need to check the address encoding algorithm
2. It's always a problem with Exodus and Atomic to understand how they derive addresses, that's why I'd avoid using them, the way I did it in the past was basically by try&error, so trying different way until I got the same address. Sometimes it was easy, sometimes I couldn't get it. I'll try to take a look if I have time.

[jaylinlucero]

thanks friends!

[jaylinlucero]

perfect 👍👍👍👍

I haven't tried to work with ONT and Exodus yet 😚😚😚

[ebellocchia]

Hi, I tried Ontology. It works in a quite, let's say, "usual" way. In the sense that Exodus always uses the secp256k1 curve for deriving keys, also for coins that are based on a different one (nist256p1 in case of Ontology). It's easier for developers because they only need to implement one derivation scheme in this way. I wrote an example here for Solana. It should work for any ed25519 coins in Exodus.

So, it's pretty easy to derive the private key, you just have to use Bip32Slip10Secp256k1 and derive the Ontology path (i.e. m/44'/1024'/0'/0/0). Funny thing, I don't understand how it computes the final address, because the method I used in the previous example doesn't work for Ontology. But at least we got the private key.

from bip_utils import *

mnemonic = "physical require taxi question have visual sound damp draft actual kangaroo gold"
seed_bytes = Bip39SeedGenerator(mnemonic).Generate()

# Derive Ontology path
bip32_mst = Bip32Slip10Secp256k1.FromSeed(seed_bytes)
bip32_der = bip32_mst.DerivePath("m/44'/1024'/0'/0/0")
# Same private key of Exodus
print("Private key:", bip32_der.PrivateKey().Raw().ToHex())

I will try to get the address (don't get your hopes up too high 🙂), but that's a good starting point.

[jaylinlucero]

I also managed to get a private key, even the script for exodus gave me the address of the ONT coin, but it does not correspond to the cryptocurrency wallet ... so I wanted to understand what is wrong here.

[ebellocchia]

Actually this doesn't make any sense. Given a private key, there is only one associated public key and therefore one associated address, so if the private key is correct it's impossible that we get the wrong address. This means that the private key shown by Exodus is not the one it uses to compute the address. In other words, it shows the wrong key 😅. In fact, I found people complaining that they got the wrong address by recovering the Exodus Ontology private key on other wallets.

It's quite a mistery, the only way is probably look into the source code of the key derivation part if available (it's not 100% open source as far as I know).

[jaylinlucero]

Actually this doesn't make any sense. Given a private key, there is only one associated public key and therefore one associated address, so if the private key is correct it's impossible that we get the wrong address. This means that the private key shown by Exodus is not the one it uses to compute the address. In other words, it shows the wrong key 😅. In fact, I found people complaining that they got the wrong address by recovering the Exodus Ontology private key on other wallets.

It's quite a mistery, the only way is probably look into the source code of the key derivation part if available (it's not 100% open source as far as I know).

Yes, of course it's a big secret... I wrote to exodus support and this is what they answered: "I can confirm that the output path below is correct: m/44'/1024'/0'/0/0 Please note that this is a non-standard withdrawal path, so it may not be compatible with other wallets."

[ebellocchia]

You won't get any information from the support, they only give you pre-defined answers that you can easily find on the Exodus website. They probably don't even know the implementation details, they are not devs. I had the same answer some time ago when I asked for Solana. At the end, I figured out by myself how it was done and wrote that example.

But I'll give it a try again.

[jaylinlucero]

You won't get any information from the support, they only give you pre-defined answers that you can easily find on the Exodus website. They probably don't even know the implementation details, they are not devs. I had the same answer some time ago when I asked for Solana. At the end, I figured out by myself how it was done and wrote that example.

But I'll give it a try again.

hi, please tell me how you managed to overcome this problem??

[ebellocchia]

I wrote it, I just tried by myself until I found the solution, there is not much else you can do

[jaylinlucero]

I thought maybe the private key could be converted into an address... there is a division between compress or uncompress...

everything should be like this: 1 private key - 1 address... I don’t understand how it could be otherwise...

maybe it’s worth trying to combine the native ONT library with your script .. and something will work out...

[ebellocchia]

No, there are constraints, Exodus is not free to do whatever it wants. It can use a different derivation path or a different way to derive keys, that's ok, but the way the address is computed is defined by Ontology and it cannot be changed, otherwise the blockchain will refuse the transactions. Exodus cannot use the uncompressed public key if Ontology states that the compressed one shall be used, or use a different hash algorithm.

What I can think is:

• The private key shown in Exodus is not the one used to compute the address, but they derive another key from it
• Exodus uses a different elliptic curve to compute the public key from the private one. I checked the Exodus source code (the small part available on Github) and only secp256k1 and ed25519 are supported, but Ontology usually uses nist256p1 (i.e. secp256r1) that it's not there. So, probably it uses either secp256k1 or ed25519, which are also in Ontology source. I've already tried to use them for getting the public key and address but without success.

May I ask why you really want to understand how Exodus computes Ontology addresses?

[jaylinlucero]

after migrating from one crypto wallet to another, I received a zero balance and this upset me greatly, so I want to understand what’s the matter...

[ebellocchia]

I've just tried Neo because it works the same of Ontology (same elliptic curve, just a different coin index) and, to my big surprise, my example code works and I get the same address of Exodus:

from bip_utils import *

mnemonic = "abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about"
seed_bytes = Bip39SeedGenerator(mnemonic).Generate()

# Derive Neo path
bip32_mst = Bip32Slip10Secp256k1.FromSeed(seed_bytes)
bip32_der = bip32_mst.DerivePath("m/44'/888'/0'/0/0")
# Same key as Exodus: Kxkt9NzCAz528FNvJaKrs3dTWo3yFEKjtmfCi8BWcXZxD6GPjwUV
print("Private key:",
    WifEncoder.Encode(
        bip32_der.PrivateKey().Raw().ToBytes()
    )
)
print("Public key:", bip32_der.PublicKey().RawCompressed().ToHex())

# Use the last private key as a nist256p1 master key
bip44_ctx = Bip44.FromPrivateKey(bip32_der.PrivateKey().Raw().ToBytes(), Bip44Coins.NEO)
# Same address of Exodus: AMCWa4mJqKuHznQL4ofgMpvRZ2rFA8HHo7
print(f"Address: {bip44_ctx.PublicKey().ToAddress()}")

So, at this point, I really think there is some bug with Ontology in Exodus, because this code shall work also for it. If they don't help, it will probably remain a mistery.

[ebellocchia]

I'll close this for now, you can reopen it if you have updates