Is it possible the hacker got a hold of an old backup of your wallet? That would explain the remaining coins if the backup the hacker got was old enough.
That is possible. So if the hacker gets the actual wallet.dat file and just plops it in his .bitcoin folder any transactions would show up in my windows client even though I still have the exact keys? I mean how does the bitcoin network know which keys are legit. Both are legit then. Who spends first, wins. |
|
|
|
If there was a means to invalidate the thieves coins or to reclaim them then the same could be done to a legitimate user.
Bitcoin is a secure system only so long as you keep your wallet secured - and sadly it seems you were not able to adequately do so.
This isn't a reason to abandon bitcoin completely or to dismiss it as flawed, but of course it's understandable that you wouldn't want to reinvest after having lost so much.
Keep an eye on that address in block explorer and you might find transactions that end up at some publicly-identifiable address, that might give you some chance of identifying the thief.
You're right this can only be blamed on me. I am the flaw with bitcoin, but let's be honest the wallet should be encrypted. The developers should've put a very very high priority on this the moment bitcoin went over $1. They knew that this was bound to happen and someone is going to get hurt and if they taken preventative measures early this could've never happened. Now that's one side of the coin, the other side is that I'm an idiot for keeping a wallet.dat file with so much money on my day to day machine - especially one running windows. I'd at least like to know who took them or find out how. Encryption only works as long as you are not accessing it. Encryption doesn't protect against malware in your scenario. So doesn't VMs btw. |
|
|
|
How would the shift affect scripts which use json calls to send coins? All current scrips would break, woudn't they?
I would just change the output in the bitcoin client. The data or machine readable outputs should not be changed at all. |
|
|
|
|
Maybe one should state a new rule:
Don't hang around on IRC with a machine storing a lot of BTC.
|
|
|
|
It's a total waste, but I have it running now (on my slow old laptop). The rate of tested passwords looks like it will be finished after 4 hours on average. Really? Just 4 hours? That's some pretty good cracker you have there. Again, the one I used the last time to test things out got about 3-4 keys per second. So 4 hours at ~100W would mean it costs less than 0.1$ to crack a 5 char password? We really need to use longer literal passwords then... I am really interested in what your strategy was. Because I really did not put much effort in it. I just took the first tool Google gave me. Maybe the high performance has something to do with the fact that I have a SSD? I tried to run the tool on a university machine with 32 CPUs and it was way slower there. Then I just created a 10 MB tmpfs (a folder that is stored in RAM instead of disk), and it went even faster (2400+ tests per second). I am at "d3x2x" now, but still not lucky. But be patient, I want to crack it! |
|
|
|
|
I think the only thing we could do is trying to find out, who it was.
But even that is pretty hard.
|
|
|
|
Encrypt wallet.dat on the air-gapped machine, correct?
Yes, that makes sure that no online machine has ever seen the private information. |
|
|
|
|
I think a shift of one would be great, then we would have that
1 BTC = $2.x
and
1 BTC = €1.x
which would fit nicely.
|
|
|
|
Air gapped (not networked) computer with bitcoin transferred over via clean USB drive.
Open bitcoin and write down automatically generated address (address x).
From networked computer, open bitcoin and send funds to address x.
Encrypt wallet.dat and shred the original on the air gapped machine. Save encrypted wallet all over the place -- hardcopy too.
The unencrypted wallet never touches a networked computer.
Yeah, I thought of that, too. I would certainly do that if I had seriously huge amounts of bitcoins. |
|
|
|
One?
Can you explain why? I don't know the low level mechanics of how files are stored on disk. The default of 3 overwrites and the very existence of an iterations switch leads me to believe that multiple versions of the same file may be remembered, even after 'deletion'. For software, one iteration is enough. You cannot find data by software then. But forensic investigators can open your disk and analyze it with much smaller tools than the read/write heads of the hard disk. They can find tiny trails of data that aren't physically overwritten completely. |
|
|
|
To be fair, these same issues exist with other disk-encryption schemes, like filevault. If someone has a keylogger on your computer, you're sunk no matter what.
I'm more concerned about the in-memory password storage and getting my computer stolen/seized when the power is on than having keyloggers/malware installed. Does GPG suffer from that too? My wallet management is meant to prevent that: http://forum.bitcoin.org/index.php?topic=15068.0Why my strategy is good? 1. As long as the special bitcoin user is not logged in, there are now key nor passwords in memory. 2. The bitcoin user only has to be logged in to make a transfer from the protected wallet. This is only a short time window. 3. As soon as the special bitcoin user is logged out, his protected data will be unmounted and everything is protected again. The only way to get the keys out of that are the following: 1. You steal my computer physically while the special user is logged in. 2. You or the malware got root access while the special user is logged in. 3. You crack the special users password (12 characters of all types) or encryption keys (AES256). |
|
|
|
Let's say your wallet does get taken by malware but you have a backup copy. Could you recover and make the stolen one invalid somehow? What happens if there are two of the same wallets on the network? I would think both would become useless.
If the attacker has spend your bitcoins, your backup is worthless. Backup protects against failing disks and such, not against attackers. |
|
|
|
There was a thread started by Vladimir, describing his scheme for backing up wallets. I can't find it now, but it should also be on the OP's list.
Backup is an easily solved task. We have a lot of solutions already in the forum. The hard task is to protect your active working machine running bitcoin. |
|
|
|
|
And I really have a stupid cracking tool, the one I already linked, one of the first Google matches. It really calls "7z" each time.
|
|
|
|
|
Can some administrator please give a response? Do you like that idea?
If you don't: Could you please explain why?
|
|
|
|
Why not simply use 7zip to create a archive of your wallet.dat with a password? 7zip does use 256-bit AES to encrypt the content of the archive, same as truecrypt. Just choose a strong password, and you'll be fine.
If the 7z AES implementation is good, this should work well, too. |
|
|
|
Your pruning suggestion will not work, because the number of accounts will also grow.
And you don't have to change the block chain format for achieving that anyway.
1. There you have me! I know of no proper solution for that either unfortunately... 2. I only worked out (with a simulation, math was too complicated for me) how much more space. I didn't feel like working this out for the current Bitcoin transaction-storing blockchain, didn't feel that that was up to me. 3. It would surprise me if the block chain format wouldn't have to be changed for it, but must admit I didn't give that too much thought as there's more issues that I'd like it to change for. 1. The solution is that computer ressources will continue growing exponentially. Bitcoin data will do definately, no matter whether you prune some trash.  3. The client can just download the blockchain and throw it away, keeping account balances and hashes of the last block in a local database. |
|
|
|
It's a total waste, but I have it running now (on my slow old laptop). The rate of tested passwords looks like it will be finished after 4 hours on average. Really? Just 4 hours? That's some pretty good cracker you have there. Again, the one I used the last time to test things out got about 3-4 keys per second. So 4 hours at ~100W would mean it costs less than 0.1$ to crack a 5 char password? We really need to use longer literal passwords then... I have a mobile Core 2 Duo with 2 GHz. It tests about 2000 passwords per second. |
|
|
|
|
VMs don't mean to protect your guest from the host, only the other way around.
|
|
|
|
It's a total waste, but I have it running now (on my slow old laptop). The rate of tested passwords looks like it will be finished after 4 hours on average. |
|
|
|
|
Show Posts
