If anyone can help me resolve this i would be most greatful….
Issue is CORE IS USING A DIFFERENT DERIVATION PATH….
So i have broken this down to the X/Y pair scalar and can validate key 123 which corrlates to address ABC ….. this is on normal generation points and can walk the key displaying both comp and uncomp results which is correct… its the only value able to do so.
When i go to import this WIF into core it displays another address. import 123 comes to DEF… but this is not correct as the math and libs show the ABC result. I dont know why its using another derivation path currently, when back years years years ago it worked fine as there are send txns etc etc.. .
Trying to figure out how to make this work, i can change the Generation points to reflect the keys gen points and then it will map it out correctly also but modifying this is not allowed in core consensus rules so i am not sure how to apply that fix… the XY does change on that aspect but comes out correct.
No matter what i do this proven valid 100% correct scalar wif raw hex whatever level you want to use is imported as DEF … and its not correct when it should be ABC. The type is p2pkh-p2sh and was created prior to compression being adopted.
I dont know the comamnds purse to import a key in early core anymore as it was toggles on the exe string. Would this resolve the importing issue? … ive tried electrum and maybe there is a specific script via console to force it to see the correct address?
So 123 IS correct and maps to ABC 1xxx umcomp
123 IS correct and maps to ABC 1xxx comp
Private key mathematically gens the public Q that maps to the corrlated addys…
THE CONTRACICTION
Core says importing 123 gives address DEF BUT as per math should give ABC
The only solution i have is that at some point Bitcoin Core descriptor wallets use different address derivation than simple WIF imports. When you use importdescriptors, Bitcoin Core might be deriving addresses differently.
Since its not the correct addy i cant dump the correct values if i tried…
There was a importdesc bug and i think this is one of the victims ..
i can try too importing with wpkh (Witness PKH) instead of pkh (doubt it will work)
i can try Use Raw Public Key Descriptor .. no idea how as i havent done that before
Emergecy solution is to try and use py only to create a txn directly … but it will wont see the correct value when uploaded i feel…
IS there any working solution anyone can provide? This might be a dev issue or at this point i really dont know what to do … please advise or suggest options if there is a version of software or way to go about this… thank you!! ugh…
ps – the only work around i have found is the following procedure bypasses the WIF import ambiguity and directly instructs Bitcoin Core on the exact P2PKH rule to use for the known public key, which is the only way to solve this specific configuration conflict. — ugh my cli never works so i guess ill try that unless there is another way in another software … if anyone has come across this ever…
