I agree, however "strong enough password" is a difficult thing to measure. Also, the list of transactions is not password protected for most wallets (there are exceptions).



WEP and Wi-Fi Protected Setup PINs are both completely broken, and have been for a number of years.

WPA1/2-TKIP (uses an RC4 cipher) has a number of weaknesses, including a practical data injection weakness and an almost-practical plaintext recovery weakness.

WPA1/2-CCMP (uses an AES-128 cipher) has no serious weaknesses, however it doesn't use a very good KDF which lends itself to offline brute-forcing attacks when weak passwords are used. This is especially true if a common SSID is also used (because it makes rainbow table based attacks possible).

(The AES cipher is believed to be very secure; there are no known practical attacks against it, although there are some concerns about the key scheduler in AES-192/256 (but not 128) possibly being vulnerable to related-key attacks one day; good news is that only poorly designed software uses related keys).

As long as we're talking about favorite strength checkers, here's mine: https://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.html

It's the open source javascript-only checker used by Dropbox. There's a description of its strengths and weaknesses here: https://blogs.dropbox.com/tech/2012/04/zxcvbn-realistic-password-strength-estimation/

What versions of the OS are/were on both hard drives?

Did you use any migration tools, such as Windows Easy Transfer?

Do you use any backup tools?

Is you PC in a domain (is it a business PC)?

Are you using Windows Server Essentials (Small Business Server) on your network?

Do you have both hard drives plugged in at once? Which HD is the new one and which is the old one (I mean their names, e.g. "C: is the old one, D: is the new one")?

What is the result of doing this (feel free to X out anything sensitive if you'd like, such as your username):
 1. Start, type "cmd", press enter.
 2. type "set", press enter.

Aside: Great post, Bizmark13!

How fast an "ordinary" computer can try passwords varies greatly depending on the wallet software and the brute-forcing software. Here's a spreadsheet which has some comparisons of several popular wallets & two open source brute-forcers running on a mid-range quad-core desktop machine:

https://onedrive.live.com/redir?resid=584f122ba17116ee%21295

Guess rates vary between 20 per second (Armory, CPU only) all the way up to 4,000,000 per second (older blockchain.info wallets, GPU accelerated). Some wallets would be even faster (Electrum, MultiBit Classic) if an open source GPU accelerated version were available.

For Bitcoin Core, guess rates vary between roughly 40 and 2,000 per second depending on whether or not GPU acceleration is used (and of course depending on the CPUs and GPUs).

This is called a "known-plaintext attack". Every wallet I've seen to date uses the AES cipher which is believed to be invulnerable to this type of attack, sorry: https://en.wikipedia.org/wiki/Known-plaintext_attack#Present_day

Do you have any recollection of your password? If so, you might be able to use one of the tools in this thread, or you could hire a service to try to recover your password.

The first message about 'ecdsa' isn't the big problem, the second one about 'A mandatory option is missing' is a problem. pywallet is expecting another '--some-option' at the command line to tell it what to do.... so the question is what would you like pywallet to do?

(Also, like MZ said just above, --help gives you a list of all things it can do, one of which you need to add after --wallet="wallet.dat")

Thanks, that's a great diagram.

Please excuse my ignorance, but does the plus to the right of Ch have three inputs, and is this considered a single operation on an ASIC? I think that's the 6 vs 7 additions per round discrepancy.

Also, should the message expansion step be included (creating W_t, the 48*3 from above)?
Should the final hash value creation be included (the 8 from above)?

Are you sure of those numbers? For example in a naive implementation, I'm counting 48*3 + 64*7 + 8 = 600 additions for a single SHA-256 block. There could be better ways of doing SHA-256 that don't naively follow the standard though... I wouldn't know....

That's perfectly fine, even if you use the same wallets (created from the same seeds) on both systems.


nerioseole alluded to one above—Electrum 2.x uses a different wallet format. If you give it a 1.9.8 wallet file, it will upgrade it to the new format behind the scenes (the seed remains the same). If you ever want to copy this 2.x wallet file to a machine that has Electrum 1.x on it, you'll need to instead either:

• Use a backup from Electrum 1.x, or
• simply restore from the seed.

We're comparing 5 seeds tracking thousands(?) of full nodes vs 14 Stratum servers... 14 > 5, and 1000 > 14—it's difficult to judge which is more decentralized IMO.


That's a good point, but conversely collusion among Stratum servers, with their small count, is easier (and likewise for dns seed servers).

I think it's too hard a comparison to reach a conclusion of one method being more "secure" than the other. Of course, the factoid doesn't say "more secure", it more carefully uses "perhaps somewhat more secure", so if you still think "or header-only clients" should remain, I'll just drop this

Isn't the source of the block headers and Merkle branches for SPV the Stratum servers?

IOW, with Electrum you're registering your addresses with one or more Stratum servers (out of 14 I think globally, if that matters) for tx notification purposes, and you're asking for blockchain headers and Merkle branches from those same servers for SPV.

With P2P clients, you're submitting bloom filters to one or more full nodes (out of thousands globally) for tx notification purposes, and you're asking for blockchain headers and Merkle branches from those same servers for SPV.

I'm definitely not an expert on Stratum, so I could be wrong here, but these two methods appear fairly similar to me (except for registering individual addresses vs. a bloom filter).

Newly created Electrum 2 (and its betas) wallets now conform to BIP-32, including the key serialization format. Electrum 1 wallets and wallets restored using seeds created by Electrum 1 continue to use the old serialization format.

In the new format, serialized extended keys are always 111 characters long (the linked standard incorrectly states "up to 112 characters" for some reason).

Thanks for clarifying, I didn't realize that. I suppose if it's effectively an ad, and is accompanied by the standard ad disclaimer, then it's not really a big deal if it's a bit inaccurate.

I just happened to come across a "factoid" (actually MZ pointed it out) that seems inaccurate to me:


That last clause "or header-only clients" is what seems inaccurate to me. Could someone point me to a rationale for that clause, or alternatively recommend how we could get it removed?

I find it a little bit concerning because it might encourage Electrum's use over a P2P SPV client, and AFAIK there's no tx-validation-security reason to do this. There may be a reason to prefer P2P SPV clients when it comes to privacy issues vs Electrum/Stratum.

I like GreenAddress/Greenbits too, FWIW, although I do find it a bit confusing for beginners. Of course for mobile use, its 2FA is only effective if you have a separate phone/laptop/PC for the 2FA bit.

They have in the past covered users' losses when the fault was bc.i's, but nobody knows if they would have been able to do so during the last big one if not for johoe's saving 870btc on behalf of bc.i, nor if they'll be able to afford their next big one (which of course I hope will never happen!).


That's the whole problem. People who don't know any better trust that bc.i is both honest and competent. While the former seems likely IMO, the latter does not, and you need to have both to prevent loss.


I agree, and that's what I find unfortunate. There are more secure online alternatives.


Electrum's model would have some security benefits over a P2P SPV model if the Electrum servers were required to use SSL, but they aren't. As it is, I see no security benefits. P2P clients d/l headers & merkle branches from 8-ish full nodes (out of thousands globally), and Electrum clients d/l headers & merkle branches from 8(?)-ish Electrum servers (out of 14 globally). Could you or Adslot be more specific on why you think otherwise?

Electrum's model does have a privacy disadvantage when compared to P2P SPV—AFAIK, Electrum doesn't use bloom filters for monitoring addresses.

That's a version 1 (what the code refers to as version 0 IIRC) encrypted wallet. There have been several different encryption schemes used for this wallet version—the only way to differentiate them is to try them all, and see which one works.

The schemes have some shared attributes: the payload is stored base-64 encoded, the first 16 bytes is used as both the KDF's salt and the encryption mode's IV (and the rest is the ciphertext), the password is UTF-8 encoded (it's not normalized), and the KDF is PBKDF2-SHA1. The scheme differences, in most recent to oldest order, are:

• the KDF iteration count is 10, encryption is AES-256 in CBC mode with ISO 10126 padding (same as version 2 wallets, but with a hard-coded iteration count)
• same as the above, but the iteration count is 1
• the iteration count is 1, encryption is AES-256 in OFB mode with ISO 7816-4 padding

Likewise, the second-password encryption has gone through a number of schemes; I think they parallel the ones above, but I'm not sure and don't have the details readily available.

The second password is also stored hashed inside the wallet file, and I do have the details of the various hashing schemes (again, password is UTF-8 encoded, most recent to oldest):

• the salt is the sharedKey field (the literal string, not the underlying UUID bytes), the hash is PBKDF1-SHA256 with an iteration count of 10 (same as version 2 wallets, but with a hard-coded iteration count)
• same as the above, but the iteration count is 1
• the hash is SHA256(password) (unsalted)

I don't understand why ppl still still trust bc.i. They've had more than their fair share of bugs[1][2][3], some of them serious and/or inept which have lead to actual btc loss.

All three of the wallets I mentioned above are SPV and decentralized: the Schildbach wallet, breadwallet, and Bither. Electrum is also SPV, but it's not as well decentralized/worse privacy (no bloom filters). Greenbits is also SPV; it adds 2FA in exchange for being centralized, and it's a good (if somewhat confusing) option.

[1]: https://bitcointalk.org/index.php?topic=581411.msg9888800#msg9888800
[2]: https://bitcointalk.org/index.php?topic=581411.msg9940868#msg9940868
[3]: https://github.com/bitcoin/bitcoin.org/pull/663#issuecomment-64975087

The very definition of spam.

The kernel version has absolutely no effect on the build output (as long as it supports LXC, which has been around for several years).


Both.... Bitcoin Core hasn't always used Gitian, but I was guessing (tbh) that it would be possible to find an older version that was using Gitian but wouldn't be easy to reproduce today.


I know he's discussed it in an issue on GH at least once as a desirable feature, but I've no idea if it's under serious consideration. (He is happy accepting pull requests, tho )