Title: Complicated help with crossed-client key compression. Post by: MrlostinBTC on March 01, 2021, 06:47:10 PM My old bitcoin wallet.dat, from client 3.24. Was mined on and before the 3.24. Wallet.dat sat for years and was accidently loaded into Doge core in 2013. I suspect it compressed my bitcoin keys. The data timestamps of btc/doge show when dumped by BTC core 13 for some reason. Clear data split by blockchain creation dates. Is there currently a way to un-compresse a Doge key/addy address? I am hoping the original data is tact. The BTC method does not work as I think it somehow changed the keys/address when Doge client got involved. Key to hex to math formula maybe?
Also having a difficult time compiling older clients, My 686 ubuntu emulation works like garbage. Any advise? Was going to try a pre-compression erra client but there are only sources online. Also strange. 1 address is coming up different 1 digit shorter in all the dumps from BTC form. 1F2f3FubHQ7v8cvcSf81xkj4rQC4URKhF - 34 digits 18w2pc9PFUfmCaR4JdKaDery3Bentp6CYy - 35 all the rest 1LJAdG24ajwgBhitKJnFfyTiSF9NaA45Jy - 35 all the rest Title: Re: Complicated help with crossed-client key compression. Post by: HCP on March 01, 2021, 10:09:54 PM As I mentioned in your other thread (https://bitcointalk.org/index.php?topic=5318082.msg56440541#msg56440541) regarding this... the private keys don't get compressed... the public keys do. As such, if you can use the --dumpwallet functionality of PyWallet, you should be able to get the raw hex values for the private keys from your wallet.dat relatively easily.
Once you have the raw hex private keys, there are lots of tools available to convert those into WIF keys that can be easily imported by most wallets. For instance, you can input the hex private keys into something like the "wallet details" tab on https://www.bitaddress.org/ (download and run offline) to get both the uncompressed and compressed addresses and WIF keys... or there are multiple python scripts/tools that should be able to do the same. Alternatively, you can probably do the reverse... and use dumpwallet in Bitcoin Core and get the "compressed" WIF keys, put those into https://www.bitaddress.org/ and you will be able to see the "uncompressed" address and WIF key (and raw hex as well). There are certainly tools out there that will take a WIF key, decode it from Base58check into the raw bytes, then drop the trailing checksum bytes and the leading "80" byte and give you the raw HEX private key... which you can then use to go back the other way. In fact, here is a Python3 script that I just wrote that does exactly that... it will take in a file of "compressed" WIF format keys... and outputs a file of "uncompressed" WIF format keys: Code: (https://keybase.pub/hcp/compWIF_to_uncompWIF.py) import os Then, if you create a text file called "compressed_wif_keys.txt" in the same location as the .py file, and copy paste the following compressed WIFs into it, and then run the script without any arguments: Code: (https://keybase.pub/hcp/compressed_WIF_keys.txt) L5cg8tbrDAFX6obhWSMktPrwDTcBX8dQz1AAmhRqidft81vFAoyX It should produce the following "uncompressed_wif_keys.txt" output file: Code: ("uncompressed_wif_keys.txt") 5KicbsCyTmgza2wzD7CVyWCKB5DW7pwvTxmfvB4pHgaH7c17BYk Also strange. 1 address is coming up different 1 digit shorter in all the dumps from BTC form. That's not really unusual... a Bitcoin "legacy" address (aka the "1"-type addresses) can be anywhere from 26 to 34 characters long. Most are generally 33 or 34 characters in length. For the record, the examples you listed are actually 33, 34 and 34 characters ;)1F2f3FubHQ7v8cvcSf81xkj4rQC4URKhF - 34 digits 18w2pc9PFUfmCaR4JdKaDery3Bentp6CYy - 35 all the rest 1LJAdG24ajwgBhitKJnFfyTiSF9NaA45Jy - 35 all the rest |