Unisat gives different public address after importing a private key

[acme89]

Hello. Two years ago I've imported a private key from my paper wallet into the blockchaindotcom wallet and from there I''ve spent all the funds from that wallet. Today I just wanted to check how importing of a private key into the Unisat works, and I've tried to to import that private key from the very same paper wallet; but to my surprise the (legacy) address which I've got was completely different. How can this be possible?

[1714619379]

1714619379

[1714619379]

1714619379

[1714619379]

1714619379

[Charles-Tim]

I do not know the reason, but if the private key is correct, this might probably be the reason: legacy address can be compresed or non compresed. If compresed or not, the address start from 1 but different. You can know from the addresses public key which start from 04 for uncompressed while 02 or 03 for compromised. Or from the private key as 5 starts the private key for uncompressed while K or L starts the compromised address private key.

[Yamane_Keto]

Are you sure it's a private key and not a wallet seed?
If it is a private key, then it maps into two addresses: uncompressed and compressed public key, but I think you mean wallet seed
which we can say that the BTC legacy wallet derivation path is m/44'/0'/C'/X/Y

C = account number
X=Receiving/Change
Y = index

Thus from one seed several addresses can be generated

[nc50lc]

How can this be possible?

I tried Unisat to reproduce your issue and found out that they cannot properly restore the address derived from uncompressed public key if provided with uncompressed WIF private key.

In simple words, if your WIF prvKey starts with '5', it's supposed to derive the uncompressed pubKey and derive the legacy address from it.
But what it does is restore the same address as the one you can restore with a compressed pubKey from compressed WIF prvKey (starts with 'K' or 'L').

If that's the case, you can open a new issue explaining that incorrect prvKey derivation behavior to: https://github.com/unisat-wallet/extension

[raybucks]

The change in the address format might be due to the wallet using a different address format, like legacy or SegWit.
Your funds should still be accessible with the private key. Try importing it into a wallet that supports the legacy address format to access your Bitcoin.

[Pmalek]

The change in the address format might be due to the wallet using a different address format, like legacy or SegWit.
Your funds should still be accessible with the private key. Try importing it into a wallet that supports the legacy address format to access your Bitcoin.

Please check the first post again. acme89 already emptied the wallet two years ago and moved the coins elsewhere via Blockchain.com. Hence, there are no more bitcoin to access on the old wallet. He just wanted to practice importing private keys into UniSat and was surprised when he noticed a different address compared to the one he funded years ago.

[acme89]

How can this be possible?

I tried Unisat to reproduce your issue and found out that they cannot properly restore the address derived from uncompressed public key if provided with uncompressed WIF private key.

In simple words, if your WIF prvKey starts with '5', it's supposed to derive the uncompressed pubKey and derive the legacy address from it.
But what it does is restore the same address as the one you can restore with a compressed pubKey from compressed WIF prvKey (starts with 'K' or 'L').

If that's the case, you can open a new issue explaining that incorrect prvKey derivation behavior to: https://github.com/unisat-wallet/extension

.....

[hosseinimr93]

5JeUTH3HH3RPDSxzU8JaRopQd9TV2dqbbaBSB1m8zcKzVQ6Nf16

This is an uncompressed private key and as stated by nc50lc, the problem is with how Unisat generates address from an uncompressed private key.

The compressed private key associated with the uncompressed private key you posted is KztQAyo4qogd3wc8ejEaYVeFGYKtiDbVhbT47CMpHGvpk741sBA1.
If you import this private key in electrum, you will get the same address as the one generated by Unisat.

[nc50lc]

-snip-

It's as what I've posted.
I think it's because since they mostly implemented the "new stuffs", they forced everything to derive compressed public keys including old uncompressed WIF prvKeys.

Since you haven't posted it as a new issue, I've opened it for you: https://github.com/unisat-wallet/extension/issues/107
You can follow that link to see if they can solve it in the new release.

[acme89]

A similar thing happens when trying to import a seed phrase from XDEFI to Unisat. While mainnet addresses are the same, the BTC testnet addresses are different.

[nc50lc]

A similar thing happens when trying to import a seed phrase from XDEFI to Unisat. While mainnet addresses are the same, the BTC testnet addresses are different.

Similar but that may be an unrelated issue.
Based from that info alone, I can tell that it's an issue with the "coin_index" derivation path used in testnet which should be different from mainnet.
Still need confirmation with testing though.

But with their "busy" developers (since the original issue I reported above is still not closed) and the issue being testnet-specific,
I wont make the effort to report this issue myself.