This image is misleading. You don't need to guess the true 256-bit private key that corresponds with the actual wallet. It is sufficient to compute any 256-bit private key whose public key hashes to the 160-bit RIPEMD hash present in the output script. Which is still infeasible, but a 2^160 address space is a completely different ballpark from a 2^256 one.

But before anyone starts worrying about that, if anyone had that kind of hashing power, at the current difficulty it is about 28 decimal orders of magnitude easier to calculate a block for the blockchain than to brute force a single 160-bit hash. In other words, no single address will ever be worth it, by a massive margin.

You're asking if you goofed by leaving a company that can (and have) refused whole classes of applications to run on their hardware at their whim, in favor of one where you can run whatever you damn well please?

No. Definitely not.

Was this wallet generated by Blockchain.info ?

If someone somehow compromised your private key, they certainly wouldn't be sending BTC to it. But there is one plausible theory to what could have happened. Previously, certain Android-based wallets suffered from a security breach caused by weak native random number generators. It could be that Blockchain.info has a similarly faulty RNG or RNG seeding mechanism that somehow ended up generating the same private/public keypair twice - either due to a significantly lower than expected level of entropy, or because of a reused seed. These things are incredibly hard to debug, but it would be very, very bad if it were true.

Say for example that the RNG was naively seeded with the timestamp of the system - two wallet addresses generated at the same time, rounded to the exactness of the system clock, would be identical. I would strongly suggest they audit the code to make sure this isn't how it's done.

FYI, the linux binary doesn't run out of the box on CentOS 6 (6.5 fully updated).

./bitcoind -daemon
./bitcoind: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by ./bitcoind)
./bitcoind: /lib64/libc.so.6: version `GLIBC_2.15' not found (required by ./bitcoind)
./bitcoind: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./bitcoind)

Supported versions are:

GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBC_2.2.5
GLIBC_2.3
GLIBC_2.4
GLIBC_2.3.2

The "problem" is that it's a zero-fee transaction that also doesn't get priority from being large or using aged coins, so most miners will just skip it. Whether it'll be dropped (by double-spending the inputs) or simply rebroadcast until someone picks it up depends on their client implementation.

SEPA or international wire? Dunno about wire, but SEPA pretty much always shows up two days after it's confirmed.

I've been doing a low 4-figure withdrawal (SEPA) every week for about half a year now, the most recent one hitting my bank account today. No hitches, except for that one time they wanted me to answer the "extended" KYC, but that only added one extra day to the withdrawal time.

I can see why people would like to do larger withdrawals to save on fees, but I'd generally recommend splitting them to avoid hitting certain limits ($10,000 being the most important one).

If you saved either the 2FA code key they give you when you first set it up, or the QR code image itself, an attacker would be able to use that to bypass 2FA.

It was about five hours for me back in January. The withdrawal was processed the next day.