If anybody may help me resolve this i’d be most greatful….
Subject is CORE IS USING A DIFFERENT DERIVATION PATH….
So i’ve damaged this right down to the X/Y pair scalar and might validate key 123 which corrlates to handle ABC ….. that is on regular era factors and might stroll the important thing displaying each comp and uncomp outcomes which is right… its the one worth ready to take action.
When i’m going to import this WIF into core it shows one other handle. import 123 involves DEF… however this isn’t right as the mathematics and libs present the ABC outcome. I dont know why its utilizing one other derivation path at the moment, when again years years years in the past it labored fantastic as there are ship txns and many others and many others.. .
Making an attempt to determine make this work, i can change the Era factors to replicate the keys gen factors after which it’ll map it out appropriately additionally however modifying this isn’t allowed in core consensus guidelines so i’m not certain apply that repair… the XY does change on that facet however comes out right.
It doesn’t matter what i do that confirmed legitimate 100% right scalar wif uncooked hex no matter stage you need to use is imported as DEF … and its not right when it needs to be ABC. The kind is p2pkh-p2sh and was created previous to compression being adopted.
I dont know the comamnds purse to import a key in early core anymore because it was toggles on the exe string. Would this resolve the importing situation? … ive tried electrum and perhaps there’s a particular script through console to power it to see the proper handle?
So 123 IS right and maps to ABC 1xxx umcomp
123 IS right and maps to ABC 1xxx comp
Non-public key mathematically gens the general public Q that maps to the corrlated addys…
THE CONTRACICTION
Core says importing 123 offers handle DEF BUT as per math ought to give ABC
The one answer i’ve is that sooner or later Bitcoin Core descriptor wallets use totally different handle derivation than easy WIF imports. Once you use importdescriptors, Bitcoin Core could be deriving addresses in a different way.
Since its not the proper addy i cant dump the proper values if i attempted…
There was a importdesc bug and i believe this is without doubt one of the victims ..
i can attempt too importing with wpkh (Witness PKH) as an alternative of pkh (doubt it’ll work)
i can attempt Use Uncooked Public Key Descriptor .. no thought how as i havent finished that earlier than
Emergecy answer is to try to use py solely to create a txn immediately … however it’ll wont see the proper worth when uploaded i really feel…
IS there any working answer anybody can present? This could be a dev situation or at this level i actually dont know what to do … please advise or counsel choices if there’s a model of software program or approach to go about this… thanks!! ugh…
ps – the one work round i’ve discovered is the next process bypasses the WIF import ambiguity and immediately instructs Bitcoin Core on the precise P2PKH rule to make use of for the recognized public key, which is the one approach to resolve this particular configuration battle. — ugh my cli by no means works so i assume in poor health attempt that until there’s one other approach in one other software program … if anybody has come throughout this ever…
