Importing correct scalar/private key – results are incorrect when using different derived paths

I would be most awesome if someone could help me solve this….

The problem is that the cores are using different derived paths.

So you can break this down to a scalar of X/Y pairs and verify the key 123, which is correlated to address ABC…. This is on the normal generation point and you can follow the key to see both the correct comp and uncomp results… That’s the only value it can be.

When I try to import this WIF into the core, I get a different address. import 123 would be DEF…but this is incorrect because the math and libraries show a result of ABC. It worked fine until a few years ago because it had outgoing txns and such, but now I don’t understand why they are using a different derivation path.

I’m trying to figure out how to make this work. If I change the generation point to reflect the key’s generation point, it also maps correctly, but changing this is not allowed by the core consensus rules, so I don’t know how to apply that fix… XY changes on that side, but it still appears correctly.

No matter what I do, this is a 100% correct scalar that is proven to be valid in raw hex, and whatever level I want to use is imported as DEF…and it is incorrect when it should be ABC. The type is p2pkh-p2sh and was created before compression was adopted.

The command parsing for importing keys into early cores was toggled in the exe string, so I don’t know anymore. Will this solve the import issue? … I tried Electrum, but I wonder if there is a specific script that forces the correct address to be displayed via the console?

Therefore, 123 correctly maps to ABC 1xxx umcomp. 123 correctly maps to ABC 1xxx comp. The private key mathematically generates a public Q that maps to the correlated addy…

CONTRACICTION The core says that importing 123 gives us the address DEF, but according to our calculations we should get ABC.

The only solution I have is that at some point the Bitcoin Core Descriptor wallet uses Different address derivation More than just a simple WIF import. When using importdescriptorsBitcoin Core may derive addresses differently.

It’s not the correct addy, so I can’t dump the correct value no matter what I try… I think there is a bug in importdesc and this is one of the victims.

You can also import using wpkh (Witness PKH) instead of pkh (I doubt it will work), you can try using raw public key descriptor. I’ve never done it before so I don’t know how. An emergency solution is to try using py only to create the txn directly… but I feel like it doesn’t show the correct value when I upload it…

Is there a working solution that someone can provide? This could be a development issue. Or I don’t really know what to do at the moment… If you have a software version or a way about this, please suggest any advice or options… Thanks!! Hmm…

ps – The only workaround I’ve found is to disambiguate the WIF import with the following steps and directly tell Bitcoin Core the exact P2PKH rules to use for known public keys. This is the only way to resolve conflicts for this particular configuration. — Hmm, my cli never works, so I guess I’ll just have to try, unless there’s another way with another software… If anyone ever comes across this…