Not entirely... where did the virus-version come from, and was it created by the same author of Zipcoin?

As far as I can tell, this link has been claimed to be the link where the virus version originally came from (although its content has since been removed): https://mega.co.nz/#!JAoyiajC!0ND16g-6qVDRGVuxnNBZmd-NInXzpbdaW9Pe9dDlDUo

The first reference I can find of that link is over in this forum by an admin, so I doubt it was created by them: https://cryptocointalk.com/topic/13908-zipcoin-zip-information/?p=116755

I posted a question asking where the link came from, we'll see if there's any reply.

There definitely is a version which contains a virus. What hasn't been decided is where that version came from, and if it was created by the author of the official Zipcoin wallet. So far, the currently posted version has not been found to contain any malware, but since any semblance of Gitian has been ripped out of it, it's very difficult to know for sure. (Gitian is what allows people to compile the software from source and see if the .exe is exactly the same as what's posted.)

As of right now, I honestly don't know, but I'd err on the safe side if I were you.

That stinks. I'm at least glad you found the source...

Has any asked a mod to see if the original post had the malicious link (not that I really doubt it)?

I can't verify that URL referenced above was in the original post, but I can definitely verify that it drops malware:

My mistake, do not include the wallet file name, I should have said run "db_recover -cv" from inside the .bitcoin directory and it will attempt to do a recovery of all wallets in the directory. On second thought though, I don't think this will help. I think it only helps if there are BerkeleyDB .log files still present, and Bitcoin removes all BerkeleyDB logs before exiting, so this command probably won't do anything (but it doesn't hurt).

I'd try the db_dump/db_load process instead, starting with the original wallet file (not the one which Bitcoin created in its attempt to do a salvage). If that still doesn't work, then it's on to pywallet...

By the way, are you sure that it doesn't look like a normal change transaction (not normal/a stealing tx would be a whole bunch of inputs and just one output). If you're not sure, please post the transaction id up...

Probably, Bitcoin will create 100 new addresses if wallet.dat is missing, and given that they got two different wallets, it sure doesn't sound like a technical glitch.

I'm sure you don't want to hear this, but to be safest you should probably reinstall everything from scratch at this point.

If your wallets were encrypted, it's very likely you have a keylogger on your system. This means: (1) don't log into anything, and (2) after your system is reinstalled (or better yet, from a different system), change all your important passwords, especially financial ones, cause it's a good bet someone else could have them now...

I'm not sure it'll help you much, but here it is anyways (with the quotes, assuming you're on Windows):


Then you can double-click it (the file), and it will display the creation time of all of the reserve addresses (I think in the UTC time zone).

That really stinks, I was optimistic it may have just been a technical glitch, so sorry if I got your hopes up.

Is there any chance the transaction you're looking at was something you initiated, and you're just confusing a full-out transfer with a change address, or was there only one output?

Regarding the log file: maybe. Most hacker victims just have their wallets or keys stolen, and then the hacker transfers the Bitcoin out later. If the hacker actually used your PC to transfer the coin out, then it would be in the logs. Also in the logs will be a bunch of "reserve" address creation messages around the time your wallet.dat was recreated.

Did you have your wallet encrypted? Did you have RPC enabled?

Have you installed or upgrading any software on your PC recently (especially from this or another Bit/Altcoin forum)?

If all the saved addresses are gone, I'd guess that either the wallet.dat file moved or was deleted (by accident? technical glitch? a hacker? hard to say...), or the place where Bitcoin Core is looking for the wallet.dat file changed/got reconfigured.

Usually hackers don't matter deleting the wallet.dat as far as I'm aware (they usually just transfer the Bitcoin out leaving you with a 0 balance but the same keys), so maybe that's a good sign....

Have you installed or upgrading any software on your PC recently? Do you have a backup of the wallet.dat? Did you ever intentionally choose an alternate datadir?

How much was in there (don't have to tell me, I just mean ask yourself)? If it was a lot and you have no backups, and if you're a techie yourself or if you're willing to enlist the aid of one (a friend or paid), you should probably assume a technical glitch (it's the best case) and do something drastic, like shut down your PC right now, and boot off of a rescue CD with some data recovery tools.

Otherwise, I guess I'd start by searching the whole HD for any wallet.dat file, including the Trash/Recycle Bin, in the hopes it was just an accident/technical glitch. If you do a dumpwallet via the debug console / RPC, it would be interesting to see the creation dates of all of the keys. I'm guessing they were all created just now when you opened your wallet, which means the original wallet.dat file wasn't where it was expected and it got recreated.

That's all I can think of for now...

I'd guess that if your wallet software were smart enough to implement Replace By Fee (and if it was standard on the network), it would probably also be smart to not have caused this situation in the first place. In other words, I think the better option would be to get your wallet's developers to implement warnings when the transaction fee is too low, and also methods to remove stuck transactions, first (not to knock the devs, all things take time to work the bugs out).

If Replace By Fee were standard, no transaction would ever be instant, even very small ones. Some see this as an improvement in security at the expense of convenience and choice, others see the improvement in security to be so minuscule, especially with small transactions, that the cost in convenience makes it not worthwhile (although I'm probably summarizing all this incorrectly).


Have you tried the advice over on this support page of theirs?

If that doesn't help, here's what I'd eventually consider.

• Transfer the remaining balance (via the Bitcoin network) from your old wallet to one of the new MultiBit addresses. This is just to ensure that you don't lose anything on the off-chance MultiBit didn't like the keys you imported (I really don't think that's the case, I'm just being safe).
• Once that transaction has confirmed, uninstall the old wallet so that it stops trying to broadcast the stuck transaction, wait a day or so, and try the advice on the linked page once again.

Those commands were an example for Windows. I'm not much of an OS X person, so I might be wrong, but give this a try.

Start in the Applications folder, then open the Utilities folder, then open the Terminal application. From here, type in this:


You shouldn't need to, but if you're interested there's a Terminal tutorial for OS X you can read over here: http://blog.teamtreehouse.com/introduction-to-the-mac-os-x-command-line

In both cases (javascript-crypto despite its many weaknesses vs server-stored keys), the level of trust you're required to give the developers is roughly the same*, as far as I'm concerned. However in the someone-hacked-the-server case, I'd argue that you'd be safer with javascript-crypto. As you pointed out a clever hacker should certainly inject difficult-to-detect malicious javascript (and javascript being a dynamic language only makes this easier to go undetected), but I'd argue that the developers/admins would eventually catch such an exploit, decreasing the count of affected users.

In the end it's all shades of grey. A particularly clever hacker might do the same to a desktop client (e.g. a pull request whose true nature went undetected for some period of time), it's just a matter of likelihood. If that's true, the question then becomes what are the chances that someone could succeed in stealing any given wallet in such an attack? For example, maybe it's 0.1% for a particular desktop wallet, 25% for a javascript-crypto wallet on a compromised server, and 100% for a fully hosted wallet on a compromised server. Or maybe it's 0.1% / 95% / 100%. I'm sure I'm not qualified to guess, though.

* You could argue that you need to trust javascript-crypto developers more, simply because creating safe javascript-crypto is somewhere between hard and impossible, and you have to trust that the devs really know what they're doing.

Completely agree, with two caveats...

I wouldn't have a problem if there was a by-default-off automatic update mechanism (although the type of user who would most benefit from this probably wouldn't know enough to enable it, which kind of defeats the purpose...).

Blockchain-style wallets, while certainly less secure than desktop clients in most cases, shouldn't be compared equal to coinbase-style wallets, which is a phenomenon I see occurring all the time (not to imply that your doing so).

Edited to add: it's not that there isn't a clear benefit to automated updates, it's just that IMHO the risks outweigh the benefits, especially for the type of user who I'd expect to be running the full-node clients.

The important point is that online wallets are less secure than desktop ones, but at the same time not all online wallets are created equally.

Some, like Blockchain, publish their in-browser code as open source (on GitHub) and do not do any private key handling on their servers making them somewhat safer. Others store your private keys on their servers, making the service more PayPal-like than Bitcoin-like.

You could lose your Bitcoin in either scenario, but the former (Blockchain-style) service is the safer of the two.

You'll need them in unencrypted format. The easiest way to get them is to log into Blockchain, go to Import / Export, then Export Unencrypted, and finally choose Bitcoin-Qt format. The private keys are the text that come after each "priv" element, and usually start with a 5 (but might start with an L or K).

If you're running the "normal" graphical version of Bitcoin, you can go to the Help menu, choose Debug window, and then click the Console tab. You can type the importprivkey commands into this window. For an example, type in: help importprivkey

Edited to add: it's much safer to simply send your Bitcoin from Blockchain to you desktop wallet. The problem with exporting/importing is that you're dealing with unencrypted keys, which might get saved to the browser's cache for example, and might get later stolen by malware. It may sound far-fetched, but as they say, "better safe than sorry."

It might, although Bitcoin Core is already smart enough to do an automatic rescan if it thinks the corruption is inside a transaction record.

Check your debug.log file (Help menu -> Debug window, then click the Open button), and search for the text "Error reading wallet database" which should have a more specific error message following it, and let us know what you find.

I'm glad things are working for you. This answer is a little late, but for future reference, MultiBit also creates encrypted backup files of the private keys as explained here which can be imported should the wallet file become corrupted for some reason.


It's biggest advantage of course is that it's a deterministic wallet: as long as you write down/print out your seed, you can always recreate the wallet with all its keys should you run into any trouble.

On the down side, it relies on a somewhat centralized system for checking transactions and balance (compared to MultiBit), and it doesn't scale well to thousands of addresses. These are pretty minor concerns if you ask me though.

MultiBit HD which is MultiBit's deterministic wallet is getting closer to release (although it's downside is that it probably won't be entirely free...)

This has actually been done before, but not to the extent that the new researchers have reached.

The basic moral of the story is "don't let someone else plug something into your PC, it might be dirty." (this rule works IRL, too, if you  s/your PC/you/  )

In other words, if you're using a USB stick to bridge the air gap, make sure it's one you bought yourself from a reputable seller, and then you'll probably be OK. I say probably because in theory, if your online PC is compromised, there are some USB sticks whose firmwares could be reprogrammed turning a clean USB stick into a dirty one.

It will be interesting to see if any malware in the future tries to do this automatically....

There was a thread that talked about this not too long ago: Offline wallet - USB key alternatives - security concerns