That depends... do you like it? (yes, I am)

Glad to hear it, that's always the easiest solution

I've bolded it above....

Although it is possible to use btcrecover against a MultiBit wallet file, it's much slower and it's harder to install the prerequisites on windows (I haven't even added instructions for this in the tutorial yet, but will eventually). Instead use one of your .key files, see here: https://github.com/gurnec/btcrecover/blob/master/TUTORIAL.md#finding-multibit-wallet-files

Here's a password recovery tool that might help (open source, written in Python): https://github.com/gurnec/btcrecover

Just a warning: it may take you a bit of reading to get it up and running. The quick start is here: https://github.com/gurnec/btcrecover/blob/master/TUTORIAL.md#btcrecover-tutorial

Please take special note that it works on MultiBit .key files, not on the wallet files themselves (more details are in the Tutorial linked above).

If you have any questions about it, please feel free to ask me.

Good luck!

Are you sure you're running 0.93 (this is the 0.93 thread after all...)?

0.92 and older had a Building Databases step, 0.93 replaced this with a much faster (1 - 2 hours long) Organizing Blockchain step AFAIK.

Speaking of updates to the dllinks.txt file (that's the file that would need updating and re-signing for 0.10.0 to become available).

You may want to consider some updates to the online dllinks.txt file at some point to reflect all of this...

E.g., removing the 32 (bit) flag from all of the Armory 0.93 versions (keeping it for ArmoryOffline though), and removing 12.04 from the Armory & ArmoryOffline Ubuntu lines until/unless you intend to distribute your own libstdc++6 (FYI a newer version isn't in the backports repo unfortunately).

It's a judgement call though....

If you think there's any chance of a hardware issue, I'd avoid copying anything besides the wallet files if I were you.... I had an issue that turned out to be bad RAM causing Armory database corruption issues each time I tried a rebuild... copying a potentially bad database might propagate whatever problem you're having.

Also, with the 0.93 just around the corner, you can either wait for 0.93 or grab the most recent beta from the 0.93 thread which offers much faster database rebuild times thanks to goatpig's efforts (I recently did a database rebuild and it took about 1.5 hours on a HD, not even an SSD).

Even Bitcoin Core blockchain downloads with 0.10 are much better, if you choose not to copy over its data directories. It can still take a number of hours, but that's a whole lot better than the day or two it used to take.

Yup, I meant only for the future. And if you've never done it in NSIS before, it's as easy as "!include x64.nsh" and then "${IfNot} ${RunningX64}" to check...

Thanks for the detailed response.


You meant no x86 releases for online Armory, correct? (otherwise I'm confused)

You should probably be sure to point this out the download page (and in future download links here) so that people stuck on 32-bit machines do not inadvertently overwrite their 32-bit versions with non-working 64-bit versions... just a suggestion.

I notice that this version is 64-bit only (I haven't checked earlier 0.92.99 releases though). Was that intentional? Historically the installs have been 32-bit executables, even on 64-bit Windows. Do you plan to drop support for pre-built Win32 binaries? Just wondering...

(also, an extremely minor nitpick: the installer installs this 64-bit executable into the x86 Program Files directory, probably because the installer itself is a 32-bit app and its directories are being virtualized by Windows)

I guess my post was too long, sorry

disablewallet=1 disables the wallet cache, which is 1MiB. It won't save you much, but it doesn't hurt.

dbcache=4 decreases the other caches to 4 MiB, which by default total 100 MiB. Setting this too low might decrease performance, though... I don't know what a good number would be, but if DnT and shorena both say 4 is a good starting point, I'd trust them, and then maybe tweak it up a bit if you have any spare ram.

It used to be that Berkeley DB was used for the wallet, block indexes and tx indexes. -dbcache affected the in-memory cache for Berkeley DB. Version 0.8.0 moved the block and tx indexes to Google's LevelDB (it's faster), and kept the wallet in Berkeley DB format (presumably so that the wallet.dat format remained unchanged for backwards compatibility). In 0.8.0, -dbcache affected both the Berkeley DB and LevelDB caches.

The patch referenced above was introduced in 0.8.2, and it modified the -dbcache option so that it only affected the LevelDB caches (since the wallet is relatively small, there shouldn't be any need to adjust it's cache size, so it was hard-coded to 1 MiB). The default -dbache in 0.8.0 was 25 MiB.

Version 0.9.0 increased the default to 100 MiB. It has a hard-coded minimum of 4 MiB (and a maximum of 1 GiB on 32-bit machines, 4 GiB on 64-bit machines). I'd imagine setting it down to 4 MiB would have a noticeable affect.

Interesting, and also quite controversial

A (slightly related) interesting fork: Tom Harding's Double-Spend Relay and Alerts. It actually made it into Bitcoin Core's master for a short while before being reverted (which I think is a shame; he put a lot of work into it and it had at least some chance of being very useful, but there were some legitimate concerns as well).

Are you talking about Blockchain.info wallets? That's the only wallet client I can think of that uses AES encrypted JSON. Or something else?

btcrecover supports searching for blockchain.info passwords, including double encryption/second passwords (you must use the --blockchain-secondpass command-line option). It's free and open source, but it does require a bit of reading to get it up and running. The tutorial is available by clicking here.

Let me know if you have any questions about it.

Edited to add: a number of individuals have commented that blockchain.info support will be able to help... unfortunately that's not true. Blockchain.info claims (and I have no reason to disbelieve them) that they have no access to either your main nor your second password.

Assuming, of course, that your adversary does not have access to your master public key, deducing that the two addresses were produced from the same seed is roughly as difficult (mathematically) as stealing bitcoin from those addresses. It would involve solving four SHA256 preimages and the two discrete logarithms (which is what secures transaction signatures in bitcoin), and would in the process give the attacker access to your master private key as well.

If it were possible, there'd be far worse problems to be worrying about....

Yes.

No.

Even if they chose to use both bip32 & bip39, that would not be sufficient to guarantee mnemonic interoperability. I said something fairly bone-headed above:

I don't know what I was thinking.... Even if wallets supported bip39+bip32+bip44, it would be close but it still wouldn't be quite enough to guarantee a mnemonic could be moved easily from one wallet software to another.

I've written (and have been improving I hope) a password recovery tool for a while now, and it includes support for Armory (that was the first wallet it supported as a matter of fact). You can find it here (it's open source): https://github.com/gurnec/btcrecover; the quick start is here: https://github.com/gurnec/btcrecover/blob/master/TUTORIAL.md#btcrecover-tutorial

Although it's not the easiest to use, it is fairly well documented, and it doesn't required that you send your wallet information to anyone else if that's a problem (if you run it offline, of course).

It's also probably faster than any alternative -- it's multi-threaded, so if you have a quad-core CPU, it'll run about four times faster than most alternatives. It also supports GPU-accelerated searches, although it's not very effective on that front for Armory.^*


That would be excellent. Of all of the wallets currently supported by btcrecover, Armory is the only one where I couldn't find a way to extract enough information from a wallet file to test for passwords without putting funds at risk.

Armory encodes private keys as 32-bit blobs with no padding (which is not a weakness by any means, just an inconvenience when it comes to this particular task). Every other wallet I've encountered so far offers some form of "trick" that allows me to extract only a portion of a private key (or a hash thereof) for password testing purposes. For example, many wallets add PKSC7 padding to the end, which allows me to extract just 16 bytes of key material (50%) plus the (useless) 16-byte padding in order to search for passwords. Others encode their passwords in hex or base58 prior to encryption, which allows a similar trick of extracting only a portion of any private key/seed material. It's not that Armory is inferior for being more concise (by not including padding and by using binary instead of unnecessary encoding) -- it's just that it's the only wallet I've encountered so far where you need an entire private key to test for password validity.^**



* It depends a whole lot on your GPU memory size and the KDF parameters used during wallet creation to determine whether or not GPU-based acceleration can help in password searches. Armory's excellent use of ROMix makes GPU acceleration hard (even with btcrecover's time-space tradeoff), so a GPU might help by a factor of 5x or so, or it might not help at all....

** which in combination with the (unencrypted) chaincode and master public key does put funds at risk

That's a shame, but thank you for the correction.