If anybody may also help me resolve this i’d be most greatful….
Situation is CORE IS USING A DIFFERENT DERIVATION PATH….
So i’ve damaged this right down to the X/Y pair scalar and may validate key 123 which corrlates to handle ABC ….. that is on regular era factors and may stroll the important thing displaying each comp and uncomp outcomes which is appropriate… its the one worth in a position to take action.
When i’m going to import this WIF into core it shows one other tackle. import 123 involves DEF… however this isn’t appropriate as the maths and libs present the ABC outcome. I dont know why its utilizing one other derivation path at present, when again years years years in the past it labored superb as there are ship txns and many others and many others.. .
Making an attempt to determine find out how to make this work, i can change the Era factors to replicate the keys gen factors after which it should map it out accurately additionally however modifying this isn’t allowed in core consensus guidelines so i’m not positive find out how to apply that repair… the XY does change on that facet however comes out appropriate.
It doesn’t matter what i do that confirmed legitimate 100% appropriate scalar wif uncooked hex no matter degree you need to use is imported as DEF … and its not appropriate when it needs to be ABC. The sort 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 subject? … ive tried electrum and possibly there’s a particular script through console to pressure it to see the proper tackle?
So 123 IS appropriate and maps to ABC 1xxx umcomp
123 IS appropriate and maps to ABC 1xxx comp
Personal key mathematically gens the general public Q that maps to the corrlated addys…
THE CONTRACICTION
Core says importing 123 provides tackle DEF BUT as per math ought to give ABC
The one answer i’ve is that sooner or later Bitcoin Core descriptor wallets use completely different tackle derivation than easy WIF imports. Whenever you use importdescriptors, Bitcoin Core could be deriving addresses in another 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 among the victims ..
i can strive too importing with wpkh (Witness PKH) as an alternative of pkh (doubt it should work)
i can strive Use Uncooked Public Key Descriptor .. no thought how as i havent carried out that earlier than
Emergecy answer is to attempt to use py solely to create a txn instantly … however it should wont see the proper worth when uploaded i really feel…
IS there any working answer anybody can present? This could be a dev subject 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 option to go about this… thanks!! ugh…
ps – the one work round i’ve discovered is the next process bypasses the WIF import ambiguity and instantly instructs Bitcoin Core on the precise P2PKH rule to make use of for the identified public key, which is the one option to remedy this particular configuration battle. — ugh my cli by no means works so i suppose in poor health strive that until there’s one other approach in one other software program … if anybody has come throughout this ever…
