That's a good first step, you've just admitted that you are capable, like the rest of us, of making mistakes (nobody should be respecting 10 people all of whom are easily bribed).


Absolutely not! However your rational are choices are limited. As with any argument based in science or logic, you can either:

• Educate/fund yourself to the point where you can make investigations and an assessment on your own, or
• Ask someone you trust who has the relevant education/funding for their opinion.

I have never, not once, been into space. Yet I still believe there is (practically) no air in space. This is mostly as a result of the second choice above.

When it comes to this particular thread, I have enough of a background in math to easily follow gmaxwell's reasoning, and to largely dismiss valiron's.

The larger problem is the hubris which valiron seems to be displaying. If valiron were a troll, this would be expected. If valiron is simply having trouble following gmaxwell's reasoning, s/he should take a moment to consider that maybe s/he wrong, given the number of opponents there are.

So....

.key files are encrypted with AES-256 (in CBC mode), which is a block cipher. It operates on blocks of exactly 16 bytes.

In order to deal with the case where a plaintext isn't a multiple of 16 bytes long, encryption tools often append additional padding bytes to the end of the plaintext to make it a multiple of 16 before encrypting it.

A very common padding standard (at least in the Bitcoin world) is standardized in PKCS7. MultiBit and openssl both use this style of padding.

When openssl decrypts a ciphertext, its exit status is zero (as you already know) if the decryption "succeeds", and non-zero otherwise. When a (properly encrypted) ciphertext is decrypted with the wrong key, the output should appear completely random. To check if a decryption succeeded, the only thing openssl can check is whether or not the padding at the end appears valid as per PKCS7.

After reading the description of that padding standard (linked above), you may notice if a plaintext is one byte short of being a multiple of 16 bytes long, the padding that must be appended is a single byte of value 0x01. That means that any ciphertext that happens (by random chance) to decrypt into a plaintext which ends in a 0x01, openssl has no choice but to assume that the decryption succeeded.

In short, about 1 in every 256 (actually slightly higher) decryption attempts will result in positives from openssl, even though they may be false positives.

btcrecover uses additional knowledge about what's in a decrypted .key file to throw out these false positives. Actually, btcrecover only bothers decrypting the first 16-byte block (in the interest of speed), and then it looks for a properly "WIF" encoded private key. This also has a chance of false positives, but it's on the order of 1 in 300 billion... much more palatable .


Thanks! Tips always appreciated!

I don't understand.... I was trying to imply "we're all alts of of gmaxwell" as being the third option (however unlikely IMO).


Into my "chart"? I'd rather think that if a government wanted to pollute this thread with puppets, they'd all be in support of valiron's FUD, not against it.

They are, for the most part, very different.

Miners (partially) calculate a double SHA-256 hash of some input.

Vanitygen is based around a bunch of much slower elliptic curve based math (plus also requiring an SHA-256 calculation, which takes relative little time).

Mining ASICs would unfortunately not be useful.

I can't directly answer your question as I'm unfamiliar with that bash script, but I can offer an alternative.

This sounds exactly like what btcrecover was designed to do. Instead of calling them "stems", it calls them "tokens".

There's a tutorial available here: https://github.com/gurnec/btcrecover/blob/master/TUTORIAL.md#btcrecover-tutorial. As the quick start says, it's a big tutorial, but you can skip a lot of it. It sounds like the first two or three parts of The Token File section would be relevant, and so would the section on Expanding Wildcards for adding numbers onto the end.

If you have any questions, please feel free to ask (full disclosure: I'm the dev of that tool).

And of course, good luck!

valiron,

Nobody's perfect. Everyone is wrong sometimes, even gmaxwell, and even you. But consider for a moment this bar graph:



Either:

• You are wrong, and everyone else is right
• You are right, and everyone else is wrong
• Someone has launched a Sybil attack against you

It takes an enlightened individual to conclude that they are likely in err despite that they may not realize why. If 10 people I respect tell me I am wrong, I have to accept that conclusion even if I do not understand why.

Of course, I would seek to understand why I am wrong, but it is not the onus of these other 10 people to be my teacher. (The fact that gmaxwell has voluntarily chosen to try to teach you, and has shown so much patience in the process, certainly says something about his character.)

I mean no disrespect. I only hope that you can be this type of enlightened individual.

Wumpus (a Bitcoin core dev) noticed the same thing last year: http://bitcoinstats.com/irc/bitcoin-dev/logs/2014/09/11

At the time, he identified them as connections from Blockchain.info, and suspected that it was a bug (of Blockchain.info's custom software).

It seems likely that the connections with that "/BitCoinJ:0.12SNAPSHOT/Satoshi:0.2.0/" user-agent are (still) from Blockchain.info: here's one (edit: oops, forgot the evidence link, here it is) from March with an IP of 37.187.136.15. Note that markets.blockchain.info currently resolves to that same IP.



That was my first thought too, however the log messages are a little misleading. That "us" IP is the IP which the remote peer claims to be connecting to, however this IP is simply added to the payload of the version message by the remote peer. Nothing restricts the remote peer from lying or being buggy (as seems to be the case here).

(FYI it's there to help bitcoin clients identify their "real" public IP in the case that they're behind NAT).

It has something to do with using a non-English letter somewhere, maybe a non-English letter in your username? I'm not sure yet.

What is your operating system?

democrite,

If you want to start messing with your MultiBit folder, you must be careful with what you do and don't deleted.

These three items are safe to delete:

These critical items you must back up:

There are some other files in there too, they contain preferences and transaction notes you've added. They're not critical to back up, but there's no reason to delete them either; just leave them alone.

If I were you, I'd
 1. close MultiBit
 2. take a copy of the two critical items above, just in case (right-click & copy, then go to another folder e.g. My Documents, right-click & paste)
 3. delete the three deletable items above
 4. re-install the latest version of MultiBit (v0.5.18) from here: https://multibit.org/

I thought it was going to be a lot shorter when I started on it.... oh, well

Also, much better alternatives can be purchased for about the same....

I wouldn't worry too much.... but here's some more detailed info. TL;DR: just read the bolded parts.

Armory's KDF & encryption for SecurePrint looks approximately like this:
(in short, it generates a random SecurePrint code, runs that through a KDF with good key stretching, and then encrypts your master private key.)

constant_pi = SHA-256(SHA-256('3.1415926...'))  # an arbitrary constant
constant_e  = SHA-256(SHA-256('2.7182818...'))  # an arbitrary constant

Step 1/3: create the SecurePrint code from the master privkey and chaincode
--------
ext_master_privkey = master_privkey + chaincode
# ext_master_privkey is now 64 bytes long and has
# 32 bytes of entropy (the chaincode contributes zero entropy)

code = PRF(key=ext_master_privkey, message=constant_e)
# where PRF is similar to HMAC_SHA-512; it requires 2 SHA-512 computations.

code = code[0..6]  # truncate to 7 bytes long
code = code + SHA-256(SHA-256(code))[0]  # append a single check byte
code = base58_encode(code)
# code now has 7 bytes of entropy (not 8 as the code comment says inside Armory)

Step 2/3: key stretching
--------
key = KDF(passphrase=code, salt=constant_e)
# where KDF is similar to ROMix_SHA-512 using ROMix
# (a memory-hard mixing function) as defined in the scrypt paper;
# it's hardcoded here to use 2²⁴ bytes (16 MiB) of RAM
# and require 2²⁴ / 64 * 1.5 = 393216 SHA-512 computations.

Step 3/3: encryption
--------
encrypted_privkey = CBC-Mode-Encrypt_AES-256(encryption_key=key, salt=constant_pi[0..15], plaintext=master_privkey)

So, brute-forcing a SecurePrint code would take, on average, about:
    2²⁴ / 64 * 1.5 * 2^7*8 / 2 = 1.5 * 2⁷³ ≈ 1.4 * 10²² Total SHA-512 operations

What you'd probably like to do next is use these results to approximate how long / how much $ it would take to brute-force a SecurePrint code. Unfortunately, that's really hard (for me, anyways) to approximate.

You can't compare Armory's KDF to SHA-512 (Bitcoin) ASICs because Armory requires 16MiB of memory to do its work. Comparing Armory's KDF to scrypt (e.g. Litecoin) ASICs might seem better, but... Litecoin uses 128x less memory than Armory's KDF. It also uses the much faster Salsa20/8 hashing algorithm, somewhere around 15x faster per block (but it uses more of them). Finally, Armory doesn't use the full scrypt... it uses a portion of scrypt (ROMix), and a modified portion at that.

To make things even more complicated, you can tweak the numbers above via a space/time tradeoff according to this formula:

table_size   = 2²⁴ / 64  # number of hashes stored in RAM when no space/time tradeoff is used
mem_required = 2^24-n  where n is in 0..18 (mem_required is in bytes)
SHA-512 operations per guess = table_size + 0.5 * table_size * (1 + (2ⁿ-1) / 2)

For the sake of a comparison to the Bitcoin network, let's pretend we can build an Armory KDF ASIC that holds just 16 hashes (has 1024 bytes of memory per parallel attempt, so not much more than 0), you set n=14, and get:

SHA-512 operations per guess = table_size + 0.5 * table_size * (1 + (2¹⁴-1) / 2) = 262144 + 131072 * (1 + 8,191.5) = 1074069504
SHA-512 operations to brute-force = 1074069504 * 2^7*8 / 2 ≈ 2⁸⁶ ≈ 7.7 * 10²⁵

If we apply the entire Bitcoin network's hash capability of 3.5 * 10¹⁷ H/s to this problem (and it's all been magically converted to Armory ASICs, and we assume that SHA-256d costs roughly the same to calculate as SHA-512), we get:
7.7 * 10²⁵ H  /  3.5 * 10¹⁷ H/s  ≈  2.2 * 10⁸ s  ≈  23 years (on average)

Of course, maybe we can build ASICs with more RAM than this and speed things up, but presumable there'd be a point of diminishing returns; I really have absolutely no estimates on that topic, and my guesses on time/spcace tradeoffs in ASICs are probably wildly off.

All of the above is missing several important assumptions:
 1. The encrypted printout was stolen (e.g. by a snooping printer), but the SecurePrint code was not.
 2. Either:
   a. The encrypted wallet file was also stolen (we need access to the chaincode, which is always stored unencrypted, to figure out if a guess is correct), or
   b. We can do EC scalar multiplications and address lookups in the blockchain at the same order of speed as the code guess rate (3.3 * 10⁸/s in this wild example), which is yet another very tall order; figure around 10,000 32-core servers, or additional specialized ASICs.

The reason for (2) above is that there's no way, just by looking at a decrypted private key, if the guess we tried for the code is correct unless we have something to check it against (either the chaincode or the blockchain, and the latter would require EC math which is also hard). Kudos to the Armory devs for not using any padding during private key encryption, which is different from every other wallet I've ever looked it.

I, for one, am not particularly concerned (but of course, keep your backups safe and offline! )

I'd only consider non-custodial wallets (where you control your own private keys) and HD wallets (for easy backup).

I like GreenAddress.it. It has packaged apps (which are all just packaged HTML & JavaScript) for Android, iOS, and Chrome for desktops, as well as being accessible from any modern HTML browser. They also have a still somewhat experimental SPV wallet for Android called GreenBits, although it's missing some features available in the (non-SPV) GreenAddress.it apps/web page. It does support QR codes, even w/o one of the apps.

It may not be convenient enough for you though.... they never store your copy of your keys on their servers, so if you want to use it on a new device which doesn't have the keys already cached (and encrypted) locally, you need to type in (or scan) your full mnemonic. I see it as a security feature, but others may see it as an inconvenience.

The only other option I'd consider is Hive Web. It also has packaged apps for Android and iOS (but not for any browser), and can be accessed from any modern HTML browser. It also doesn't store your keys online (for better or worse).

Comparing the two, Hive has a simpler (IMO) interface than GreenAddress.it. On the minus side, it's not multisig and therefore can't offer 2FA nor GreenAddress's optional centralized "instant confirmations". It has no QR/camera integration, although it can display QR codes and it does support its "waggle" address sharing feature with other nearby Hive users. It also doesn't support multiple accounts based on a single mnemonic, nor does it support read-only logins as GreenAddress.it does (which is nice for public terminals, as long as your OK with the potential loss of privacy). (FYI Hive for OS X is something completely different & incompatible.)

I wouldn't touch blockchain.info (for security reasons) nor BitGo (for philosophical reasons).

Finally, although both Coinbase's and Coinkite's default wallets are custodial, they also have multisig options you may want to consider (I've never used either and so can't comment).

Just my 2¢....

Certainly there isn't (and I'm happy that some people realize this); there isn't even an "official" desktop wallet.


I'm sorry that I'm not directly answering your question, but web wallets have at least one big disadvantage. Even if they're non-custodial (if you control your own private keys), they're still auto-updating.

With iOS (actually I'm not entirely sure about iOS) or Android, the application author must log into their Apple/Google account in order to upload a new version of their wallet (which then gets reviewed, signed by Apple/Google, and then finally published to the store).

With web wallets, no such extra layer of security exists. If a hacker manages to break into the web-wallet's website, they can upload their own version of a web wallet which steals your password and/or your private keys.

In other words, with apps or browser plugins, a hacker has to first break into a Google/Apple server or a Google/Apple account. It's not an insurmountable goal by any means, but it is more difficult. That's why I'd avoid them if I were you.

Of course, there's always a security/convenience trade-off. It's just that whatever convenience you gain in using a web wallet (vs. a mobile or brower-plugin wallet) is pretty small IMO compared to the security you gain from using a mobile/browser-plugin wallet.

The Cisco 2900 XL series is painfully outdated... they're not even GigE capable (well, there are GigE modules you can plug in, but your module is a 100BASE-FX module). If memory serves, they also don't have per-VLAN bridging tables, which can be a very confusing cause of problems in certain setups.

IOW... I don't mean to be rude , but this thing is pretty much worthless. It'd probably cost you more in just power to keep something like this plugged in for a year or two than to just buy a new or lightly used cheap 24-port switch in its stead.

(also, this is quite off-topic for this subforum....)

Looks like you can blame this one on Google

pip versions prior to 1.4 (which you three apparently have) will inadvertently install pre-release versions of libraries uploaded to PyPI, and Google uploaded a broken pre-release of Google protobuf on May 1^st (here's the bug report).

Luckily, the are two easy work-arounds. (1) upgrade pip (this option will overwrite the system-provided pip):


or (2) force pip to install the most recent stable version of protobuf:


After doing one of the above, just install Electrum normally.

You might find this thread on the topic of some interest: https://bitcointalk.org/index.php?topic=682842.0;all

Personally, I'm fine with a well-shuffled deck of cards.

I agree with the latter half of your statement, but not the former. Please read this earlier post....

Have you tried sideloading it from the windows store here?

In other words, whenever Electrum saves the wallet file, it does a normal delete, and then creates a new wallet file. If OP shredded his wallet file, he only shredded that most recently saved file. Other older copies of the wallet, as deleted by Electrum, might still be on the drive somewhere.