The average user will want to use a brand name they're familiar with; if we can continue to convince early adopters that bitcoin is a good idea, eventually PayPal or one of its competitors will start supporting it.  I hope.

No what we need is to kick paypal and liberty reserve out of the middlemen position.

If Bitcoin is really successful then it would be a threat to the dollar and the power that it holds.

In jgarzik's original implementation, an attacker can pre-generate a rainbow table with 2^32 entries, and that lets them take a shortcut so they only have to try 2^32 bits for any particular scratch card (algorithm is, essentially, "foreach value in 2^32: do some complicated math, then see if the result matches a value in the 2^32-size rainbow table; if it does, you've found the unknown 2^64 bits").

Once press coverage hit that bitcoin blows and "theShitCoin" is the next best thing, the public will probably follow.

The modification to repeatedly hash the 64 bit password is a good idea, and should prevent square root attacks. I would probably have used a simpler iterative formula, but that one seems safe enough. SHA512 is notorious for speed variations on different architectures, but compared to the time to type in the password, that should be ok. Where does the magic number 108333 come from?

Because they don't want to give away their "real" money? Some will think "hey, if anyone can generate these 'Bitcoins' it can't be real money!".

Hrmmm.. not so sure about that one.

If it is determined that btc2 has absolutely no flaws (probably by the bitcoin community) then bitcoin would quickly deplete to 0 dollars value. People would forget about it, and move on to btc2.

beware man! The FBI/etc. is already tracking you!

I have looked into this, and you do need the public key to break it. (Also I was wrong about Pollard rho being suitable, but the other two are.) Bitcoin does not reveal the public key until the tx is spent; only a hash is revealed until then. However the spending tx is vulnerable while moving through the network on its way to a block. A miner or peer could hold the transaction, break the key in 2^32 work, and substitute their own spend.

As far as the algorithmic details, here is baby step giant step. Public key Y, private key x, and generator G satisfy:

Y = xG

x is of the form s + k, where s is known salt and k is unknown 64 bits. Split k into left and right halves l, r:

k = l*2^32 + r

with l and r 32 bits. Then we have, substituting for x in the first eqn:

Y = (s + l*2^32 + r)G

Y + l(2^32(G_inv)) = (s + r)G

We precompute all 2^32 values of the RHS and store them in a hash table. Then we sequentially try the 2^32 values for l in the LHS and look for a match in the table. That gives us l and r, which gives us the private key x.

What? You had signed an NDA agreement? Why did you not state this earlier? If you went through the trouble of signing legal paperwork, why didn't you make up a contract to ensure the safety of your money as well? You are clearly lying here.

Also, how did you sign this? Obviously you did not meet mtgox. Probably not through mail or fax as you've been asking for contact information. So please do inform us, how did you arrange for this NDA with MtGox?

Obvious criminal is obvious.

Think of this as a 192-bit salt.  It is well known how to use multiple salts.

I seriously doubt you can get anything close to checking a trillion combinations per second on any modern GPU.

That's how my patch is implemented, yes.

You can make it stronger by, say, having 1000x 176 bits of well known private key, 64 bit password, and 16 bits of brute force required to redeem.

It's not safe to have only 64 bits of the private key be unknown. This can be broken in 2^32 work using such algorithms as baby step giant step, Pollard rho, or the kangaroo.

It's also not working for me. Probably just temporary Tor problems.