Issues with Importing Old Keys

3 replies 128 views
Posts: 22 · Reputation: 134
#1Jun 20, 2023, 10:52 AM
I'm having trouble importing a WIF that's legit but it's from way back when. I've made adjustments for that import bug on pre-compression addresses. Tried importing it and got a coding error. This happens both on the original and the recalculated address that actually matters. Is there another way to handle this? I've checked the hex and checksum repeatedly… base58 and ecdsa too. I have signatures that confirm the results are correct. I’ve run the calculations a hundred times. I’ve tested earlier versions, tried command-line import and the GUI... only thing I haven’t done is load it on Ubuntu, but I assume I'd get the same result. Is this something a developer needs to tackle? I just want to import it and sort this out. The uncompressed version imports fine, but the compressed one throws an error Invalid private key encoding (code -5). The hex import also gives the same error. There’s a compression flag and an ECDSA bug involved here, so both addresses can actually work with the same private key based on serialization. How do I fix this? I can compute both, but they just flip back and forth. Running low on ideas… any help would be great. Thanks! It’s more complicated than I’m letting on, and I’ve gone through tons of validations and tweaks. I keep getting the same results, and I’m thinking if there’s a different way to import or if I’m missing something... The Core error means it’s rejecting the encoding format, not the key itself.
3 Reply Quote Share
gr3g.0rbitHero Member
Posts: 1025 · Reputation: 2646
#2Jun 20, 2023, 03:17 PM
Try to explain the steps that you did to encode the private key to WIF compressed. Because the error is surely caused by something as simple as missing/wrong "network byte", "compression flag byte" or "checksum" since the uncompressed form works. Or if you have an air-gap machine, you can use this tool offline: github.com/iancoleman/keycompression
4 Reply Quote Share
Posts: 22 · Reputation: 134
#3Jun 22, 2023, 08:37 AM
I think i fixed it.. Its added and i can pull the addresses up in core. It wasnt the key more so the software rejecting it. I dont like this new way of doing it, as i had to repeat it about 20x over .. true false etc..  but in the end it took the checksum and key. just having db issues now where its out of order on child and parent blocks and i really dont want to close it I have all the steps noted and formulations, which ill try to do the cliff notes if i still have a issue so you can go down the rabbit hole I just thought there might have been a more direct way to accomplish this via dev coder from core. The comp flag i took into account and the checksum also even the byte too.. it was something else.. besides all the other variable, convergence and the resolving .. im leaning towards a few reasons.. well see what happens. no -5 so ill take the small victory for now heh Nope still stuck..   I dont think you can spend a uncompressed on a compressed in descriptor -- it takes it as watchonly.... ....and legacy import wont work on the compressed side... so much fun
2 Reply Quote Share
gr3g.0rbitHero Member
Posts: 1025 · Reputation: 2646
#4Jun 24, 2023, 04:56 AM
It's imported as watch-only if the descriptor contains a public key and the wallet is watch-only in the first place ("Disable Private Key" toggled). What you'd want is to create a "Blank Wallet" and import a descriptor containing the compressed WIF private key (starts with K or L). It works on compressed WIF, that "encoding error" is literally what it means.
1 Reply Quote Share

Related topics