Are you running on Windows or Linux (or MacOSX)?  Have you confirmed (ie. with netstat) that it is actually a Bitcoin Core process that is using port 18334 and not some other system process? |
|
|
|
OK, let's take another look at this...  To dump out the wallet INCLUDING your private keys to the screen ONLY: pywallet.py --dumpwallet --wallet=C:\Users\Catherine\Downloads\pywallet\recovered_wallet_1511377727.dat --passphrase="YOUR-PASS-PHRASE"
To dump out the wallet INCLUDING your private keys to a text file: pywallet.py --dumpwallet --wallet=C:\Users\Catherine\Downloads\pywallet\recovered_wallet_1511377727.dat --passphrase="YOUR-PASS-PHRASE" > C:\Users\Catherine\Dowloads\pywallet\walletDump-withKeys.txt
When trying to dump wallet with private keys to a text file i keep getting a syntax error message I copied the command line shown Thanks if you can help me get it running. Can you please be more specific about the syntax error message that you were getting when you trying copying the command lines that I recommended earlier? Are you able to copy/paste them from the terminal window? It's difficult to know what the actual solution is, when the actual problem is not well defined |
|
|
|
2. I have WinHexed that recovered .dat and it does have a marker for magic bytes 62 31 05 00 09 00 00 00 & bestblock 010962657374626C6F636B. Is a wallet found with 1 key in MAKOMK wallet-recover-0.3 a viable wallet? or are these markers added in when a recovered-wallet.dat is created?
The tool is simply trying to find the "key" markers by searching your entire drive... then it attempts to extract the raw bytes at this points and then puts them into a new "wallet.dat" (ie. the recovered-wallet.dat file) as the private key... As such, the markers you are seeing (magic bytes and bestblock etc) are likely the ones placed there by the recovery tool when it created the recovered-wallet.dat  |
|
|
|
Am I screwed ?
Pretty much... what has happened to the drive you "recovered" the files from since 2014? If it has been used, written to, formatted etc... the odds of a "good" recovery are usually quite poor. Yes that's the person I contacted.
Are you sure? because in your post in the other thread you mentioned "David" from "walletrecovery.info"... and not "Dave" from "walletrecoveryservices.com" PS : David the owner of walletrecovery.info did the pywallet search for me (for free).
They are two different services/people... |
|
|
|
i tried to fork the bitcoin 0.21 and to compile it throught WSL and Ubuntu 18.04TLS.
When you say "fork"... did you actually make any edits at all to the source code? or did you simply clone the github repo and then attempt to compile it?
EDIT: I actually just now installed WSL(2)... Ubuntu 18.04... cloned the bitcoin repo then followed the steps here: https://github.com/bitcoin/bitcoin/blob/master/doc/build-windows.mdIt compiled without issue...  When you did this part: Ubuntu Bionic 18.04 1: sudo update-alternatives --config x86_64-w64-mingw32-g++ # Set the default mingw32 g++ compiler option to posix. Did you actually select the option that says "posix"?  I ask because the footnote attached to that command mentions issues with std::mutex... which is also on line 57 in threadsafety.h: 1: Starting from Ubuntu Xenial 16.04, both the 32 and 64 bit Mingw-w64 packages install two different compiler options to allow a choice between either posix or win32 threads. The default option is win32 threads which is the more efficient since it will result in binary code that links directly with the Windows kernel32.lib. Unfortunately, the headers required to support win32 threads conflict with some of the classes in the C++11 standard library, in particular std::mutex. It's not possible to build the Bitcoin Core code using the win32 version of the Mingw-w64 cross compilers (at least not without modifying headers in the Bitcoin Core source code).
and: // StdMutex provides an annotated version of std::mutex for us,
// and should only be used when sync.h Mutex/LOCK/etc are not usable.
class LOCKABLE StdMutex : public std::mutex
{
public:
#ifdef __clang__
//! For negative capabilities in the Clang Thread Safety Analysis.
//! A negative requirement uses the EXCLUSIVE_LOCKS_REQUIRED attribute, in conjunction
//! with the ! operator, to indicate that a mutex should not be held.
const StdMutex& operator!() const { return *this; }
#endif // __clang__
};
|
|
|
|
But that doesn't make any sense, the seed phrase are shown on their application so they should be able to see my seed phrase and use it to recover and access to my funds right? How come these wallet providers don't know my seed phrase when they are the one giving it to me?
Not all software you install and use is spyware... not all the data that you generate and store on your computer is automatically sent back to "Big Brother"... Granted, there have been "malware versions" of popular wallet software that do exactly what you're talking about... they impersonate legitimate software and are designed by the thieves to steal your private keys or your seed or just automatically transfer all your BTC out to their addresses. However, all the reputable wallets like Electrum and Bitcoin Core etc... are well known, open-source and provide digital signatures for the application executables/installers or digitally signed SHA256 checksums of the same. This allows the user to verify they have a legitimate copy of the application and because of the open-source nature of these applications, it's possible for users to review the code and make sure nothing nefarious is happening in the background. |
|
|
|
...and this, ladies and gentlemen, is why "security through obscurity" and attempting to do "clever things"™ when trying to secure your private keys is simply a "bad idea"™ As unfortunate as it is for OP, I hope that this might help persuade people who think that doing things like re-arranging 12/24 word seeds, or substituting words or using some other "clever" process to try an obfuscate their private keys/seeds etc is just not a great plan. It should hopefully also act as a cautionary tale about leaving coins in wallets that you did not create yourself and/or have not "tested" the backup/recovery process. At the end of it I had data. one of which said DO_NOT_DELETE_72aXXXX a 32 bit hex key another an image of a playing card which I think was the image to remember from the game. when you say "32 bit hex key"... do you mean 32 characters? |
|
|
|
Thanks for your response, I don't know any of the public addresses associated with this wallet.dat. From my understanding you need atleast 1 to dumpwallet. If I download full node, will the addresses show up? How can I recover something off of this wallet.dat file?
No, the fact that you don't know any of the public addresses associated with the wallet doesn't matter... dumpwallet only needs the wallet.dat to be unlocked using the walletpassphrase (if any) and you say the wallet isn't encrypted... so if you can load it up in Bitcoin Core, then you can just go into the console and use the dumpwallet command... all you will need to use as a parameter is the full path to the output file. for instance: dumpwallet "~/wallet_dump.txt"
Then you should be able to open the output file with a text editor and see all the private keys in WIF format... Alternatively, you can try and get PyWallet working... and use it's --dumpwallet command (note that this results in different output to the dumpwallet in Bitcoin Core)... If you're having trouble getting the latest version working due to issues with the updates that jackjack is in the middle of, I still have a fork of the "old" version here: https://github.com/HardCorePawn/pywalletthis old version is NOT compatible with Python 3... it requires Python 2.7 |
|
|
|
The initial error you were getting seems to be a known issue with the updated version of PyWallet (jackjack is busy updating it). You would need to try an older version of Pywallet... or wait for jackjack to resolve the issue. I have a copy of the older version here: https://github.com/HardCorePawn/pywalletNOTE: It requires Python 2.7... it will not run with Python 3. As for the private keys, it should not have "compressed" any keys... As you've discovered, a private key can be converted to compressed or uncompressed public keys, which then leads to different addresses being generated. However, the underlying (hex) private key will remained unchanged. If you are able to load the wallet into Bitcoin Core, does the dumpwallet command in Bitcoin Core work? What WIF format keys are you getting? Otherwise, the output from PyWallet's dumpwallet should have given you the raw hex encoded private keys that you should be able to use to generate compressed/uncompressed public keys and WIF's etc. |
|
|
|
Also ensure the transaction fee rate at least 1 sat/vbyte, because AFAIK Bitcoin Core also shows same error if transaction fee rate at least 1 sat/vbyte.
It isn't a "min relay" error... it is "mempool min fee"... because of the huge size of the mempool... transactions that are extremely far away from the tip get purged (I believe the idea is that you no longer have to wait 14 days for the transaction to get "dropped" if there is literally 0% chance of your transaction getting confirmed within that timeframe and also to keep the mempool memory usage size under control). The 2 places I know of that give an indication of what the "mempool min fee" likely to being currently used by default nodes are: mempool.space:  Check the "purging" value... currently any transaction with less than a fee rate of 6.5 sats/vbyte will likely be removed from a (default configured) node to try and keep the mempool memory usage down at the 300MB range. or, statoshi.info:  The bottom graph on the "Memory Pool" page shows the "mempool min fee" rate... |
|
|
|
so first I tried and copy a key, but it isn't one of 12 words (as many people comments). If you can still use the original version... there should be an option in the "Wallet" menu that says "Seed"... if that option is available, you should be able to get the "12 words". |
|
|
|
|
Likely because in QT you have the "Map port using UPnP" option checked... Check "Settings -> Options -> Network" tab.
Note that the options used in QT Settings/Options are not necessarily the same options that will be used by bitcoind... as bitcoind relies solely on bitcoin.conf (and commandline arguments) to get any "non default" settings.
|
|
|
|
Now the textdocument contains something like this: 'ecdsa' package is not installed, pywallet won't be able to sign/verify messages ERROR parsing wallet.dat, type b'setting' key data: b'\x07setting\x0caddrIncoming' key data in hex: b'0920357474696e670c62264724966e36fdfd96e77' value data in hex: b'd83b0200' i have changed most letters for security reasons  And powershell: PS C:\Python27> python pywallet.py --dumpwallet --wallet=wallet.dat > wallet.txt pywallet.py:22: UserWarning: Python 3 support is still experimental, you may encounter bugs WARNING:root:pycrypto or libssl not found, decryption may be slow Traceback (most recent call last): File "pywallet.py", line 2316, in parse_wallet item_callback(type, d) File "pywallet.py", line 2654, in item_callback if not json_db.has_key('settings'): AttributeError: 'Bdict' object has no attribute 'has_key' PS C:\Python27> Possibly either a bug that jackjack has introduced while making the upgrades... or the wallet file has an unexpected key/data contained in it that is causing PyWallet to freak out. Looking at the current Pywallet issue list on github, I found this: https://github.com/jackjack-jj/pywallet/issues/27So, it seems that you're not the only one having this problem... So, I would suggest you either use an older version, or wait until jackjack fixes this problem. I have a fork of the old version here: https://github.com/HardCorePawn/pywalletNOTES: It is NOT compatible with Python 3. It requires Python 2.7. Also, it uses the "old" command line format for recovery... so it needs the --datadir option again... but it doesn't try anything fancy and just ignores any "unknown" fields that it encounters... I've been able to dump pretty much any "valid" wallet using this version. |
|
|
|
it's the way you're using the --recov_size parameter... I think the '.' character and all the extra 0's might be confusing it... Try using So, full command: python pywallet.py --recover --recov_size=8Gio --recov_device \vaio\desktop --recov_outputdir \vaio\documents
|
|
|
|
If you have BIP38 encryption on your paper wallet with a passphrase, you'll have to go to Bitaddress or something similar for it to be decrypted into something starting with either 5, K or L. After which, you can import the private keys. I recommending downloading the source code from here: https://github.com/pointbiz/bitaddress.org/releases. Choose the source code zip and extract it. You should see a html file and run it with your internet connection turned off. If: - you have an android device... - AND your paper wallet is BIP38 encrypted... - AND your paper wallet has a QRCodes... Then, you can use Mycelium to easily scan the (encrypted) private key QRCode and it has BIP38 decryption built in... it will even "auto scan" the blockchain to determine if the paper wallet actually holds any funds. |
|
|
|
Last week we cracked a multibit wallet with 11.8 BTC that had been inaccessible since 2013 and presumed corrupt. So, it wasn't actually corrupt, just an incorrect password was being used? Did the user actually recognise the password that was found or had the application applied some random/different password? There seem to be a lot of users with multibit wallets that claim their passwords don't work... and they're 100% sure the password is correct. Since BTC broke $50k, I've been getting an average of 1 PM a day from someone struggling with old MultiBit wallets... it would be nice to know if they just have the passwords wrong, or if the application did "something dumb" and encrypted the wallet using a different password/key or something. |
|
|
|
Just as a warning for others... Magnum wallet seems to have "disappeared"... I get NET::ERR_CERT_DATE_INVALID errors attempting to connect to the website... the github is empty and on twitter we have this: https://twitter.com/Magnum_Wallet/status/1333472916588081154So, the wallet service was officially shutdown back at the end of November 2020 There was also a user who recently posted a thread trying to get coins out of a Magnum wallet but having issues... but I can't find their post right now. TLDR; Don't try and use Magnum wallet, it's dead. |
|
|
|
So, they basically "stole" all the "leftover BTC" from these dormant accounts... all in the name of KYC  Bitcoin was created to get away from precisely these types of centralised shenanigans... Satoshi would be rolling in his grave! |
|
|
|
|
Show Posts
