|
Tried downloading the bitcoin qt version 8.5 but it doesn't contain an exe or at least I can't find it, so I can't get it set up. Any ideas please.
Sorted thanks.
|
|
|
|
|
I can let you see a larger chunk of text if you think that is safe for me.
|
|
|
|
weird... then is the highlighted text that has been partially redacted the Bitcoin Address? Because it doesn't look like that address is used in that transaction at all??!?  But like I said, it is very difficult to interpret what is going on when you're only providing heavily edited data  In any case, you're just looking at a debug.log from an early version of BitcoinQT (aka Bitcoin Core)... You likely won't discover anything of great value by analysing this.  Yes it Is "the" Bitcoin address, just teasing me at every turn   |
|
|
|
I'm not sure how that relates to the "NotifyAddressBookChanged" snippet that I posted... the mostly obscured highlighted text (which should be the Bitcoin address) listed in there does not seem to match either of the addresses displayed in that transaction... It's difficult because all the debug has been partially redacted, but I don't see the text: "MQwdmSZfau9X" in either of those addresses... are you sure you are looking at the correct transaction? After the address comes ismine=0 status=1 received getdata for: tx and then the hash that you see that I have used on explorer. |
|
|
|
What is meant by a transaction? I don't think he really did any transactions or have I got the wrong end of the stick again No... it was the client accepting a "Transaction" (most likely from an external peer) as being "valid" and adding it to the local mempool of the node. It is not necessarily a transaction that the user of the local node was creating/broadcasting. That address being present again is annoying, why is it there and what is it saying about it? The thing that should concern you the most about that address is the fact that it says "ismine=0"... this, combined with the fact that it is being output from the "NotifyAddressBookChanged" function would tend to indicate that it had either been added as a "watching-only" address, or as a "Destination Address" (ie. an address that you're going to send coins to)... as the wallet does not appear to contain the private key for that address... otherwise it would have stated "ismine=1" I would check the TXID that looks like it is output after it... and see if that TX was "Receiving" coins to that address... I suspect it was.  Thanks again for sharing your knowledge, I think I understand what your telling me. He possibly sent some funds to that address as a test after he had messed up? I don't believe he would know how to create a watching only address. That Python script you created looks good, sort of like a less moody pywallet. I haven't done a hex search for the 0201010420 marker on the whole drive yet. I suspect I would get thousands of hits. It would be awesome if the script rejected all addresses except the one you know contains funds. Cheers again. |
|
|
|
What is meant by a transaction? I don't think he really did any transactions or have I got the wrong end of the stick again That address being present again is annoying, why is it there and what is it saying about it? |
|
|
|
The wallet file seems to have a space in the name... Is that correct? If so you'll need to wrap it in " "s otherwise Python thinks you have moved onto the next option... C:\Python27\python.exe C:\Users\Catherine\Downloads\pywallet.py --dumpwallet --datadir=F:\ --wallet="F:\wallet 96kb.dat" > C:\Users\Catherine\Downloads\pywallet_output.txt
Yes it has a space, I could rename it with no gap. Thanks. |
|
|
|
I'm not sure what you mean by "default address," are you reffering to the receiving address? From what I've noticed Core issues receiving addresses in the order they're listed in the keystore. The hdkeypath indicates their position, and Core will display the keys in that order. For example:
First address to display: hdkeypath=m/0'/0'/0'
Second address to display: hdkeypath=m/0'/0'/1'
So on and so forth.
Each bitcoin core HD wallet has one private key (and an associated address) that's used as the HD seed, but if I'm not mistaken core avoids the use of this address as a receiving address.
This is in a older non HD wallet, don't know if that makes a difference? |
|
|
|
|
What is the default address in a bitcoin core wallet and what determines it being the default? Cheers.
|
|
|
|
Ok... try this: C:\Python27\python.exe C:\Users\Catherine\Downloads\pywallet.py --dumpwallet --datadir=C:\Users\Catherine\Downloads\pywallet --wallet=C:\Users\Catherine\Downloads\pywallet\recovered_wallet_1511377727.dat > C:\Users\Catherine\Downloads\pywallet_output.txt
That will dump all the output from the script into a file: C:\Users\Catherine\Downloads\pywallet_output.txt You'll be able to open that with a text editor. It'll make it easier to view/read and search. At the very top of the file, does it say "The wallet is encrypted but no passphrase is used"? You should also see some records below it that have names like: "addr", "compressed", "encrypted_privkey", "pubkey" etc Sorry to pester you again but I can't seem to dump an unencrypted wallet file I have placed on a usb stick via pywallet. It isn't one I have recovered via pywallet, it is a wallet.dat I took off the old hard drive. The usb stick is F: and the file is called wallet 96KB.dat. I want to confirm I am typing the correct command, or whether the wallet just won't dump via pywallet. Thanks again. This is a screenshot of the command I used and the error. https://imgur.com/a/1jm0Ggo |
|
|
|
Thanks. |
|
|
|
|
Does a 00 in a private key indicate a corruption of the key ie 249C00. Thanks if anyone knows.
|
|
|
|
|
What does pywallet use for it's search, is it purely the 0201010420 sequence or other markers as well? Cheers.
|
|
|
|
So the plot thickens. I tried dumping it with pywallet without a passphrase, and it did, and said it is unencrypted. When the wallet is examined for info using the bitcoin-wallet.exe in daemon, it says it is encrypted. I have also used a passphrase with pywallet and it told me passphrase is correct I think the wallet file maybe has a passphrase assigned to it, but the mechanism for using it is maybe damaged. So anyway, the cni address is shown as the default key, and nearly 200 other legacy keys are dumped with private keys(which don't show up when loaded into bitcoin core) and the key I need is not present. The address of interest is just shown near the bottom with the cni address, but it's private key isn't anywhere to be seen  So I thought well, the wallets unencrypted, time to bring out winhex and run the old 0201010420 search. Sure enough it found all the markers for the private keys and I tried one on bitaddress(offline of course) and It happened to be the cni address and it all tallied up. I found this excellent post on stack exchange which tells you a few markers to search for, which I tried out and and confirmed all of the ones relevant to an unencrypted wallet. I searched the key(00 01 03 6b 65 79) marker and found that 0201010420 followed it, exactly the same amount of bytes away, for every key in the wallet But, and it's a big but(no pun intended) their is one key that has some of it's bytes zeroed out including the preceding 0201010420 marker but I do know it's position by counting it's distance from the key marker My thought is that maybe a script could be written by someone to guess the missing hex characters(could or couldn't be possible in a reasonable time frame I assume). Or search for chunks of what I can see of the key on the whole hard drive with winhex, which I would assume will be a long process, but I can use various size chunks of the remaining hex traces and they're are consecutive runs of bytes that should be pretty unique, even throughout a whole hard drive. Anyway, sorry to ramble on but that is where I am with it now. Cheers. https://bitcoin.stackexchange.com/questions/41447/filesystem-is-corrupt-how-to-find-wallet-dat |
|
|
|
Ahhhh, in that case, I suspect that the "1L5s" address might have actually been in the old wallet as a "watching only" address... and the wallet didn't contain the private key for it.
It's also possible that the file was just damaged and the private key data was unable to be extracted.
Most likely it's the latter, as he is even less bitcoin savvy than me, hence the mess he has created. If I placed the file in the pywallet folder, do you think I could dump it there, even though it isn't a "recovered" wallet? |
|
|
|
Correct... Bitcoin Core is basically bitcoind with a pretty GUI on top... so anything that Bitcoin Core would do, bitcoind would also do.
Grrr, okay thanks for your help as usual. |
|
|
|
In any case... if you can see the private key for the address you're after... what is the issue? Can't you just go and import this key into a wallet of your choosing and recover the funds? Or are you just trying to work out the technical workings of Bitcoin Core and how it goes about updating wallet files? It only shows the 1cni address, not the other address that is next to it in the hex view. That is the one with the 32btc. Cheers. |
|
|
|
|
Show Posts
