My old Xeon server can crack a 51 bit key (using BSGS) in around 5 minutes, and 52 bits in around 12 minutes, so the chances of a successful attack on a similarly weak key seem good. Such an attack would be of little use now, since the weaker keys were found (presumably by brute force?) long ago. I guess if the person claiming the puzzle prize didn't include a sufficient transaction fee, the time for the attacker to crack the key would be higher.
that's not why we are using hash of the public key. the hash is used because if in case some day there was a way to solve ECDLP faster the funds could remain safer. otherwise right now with what we have as algorithms and hardware to find the private key by just having the public key.
256 bit is HUGE. and "bitcoin clients" don't create weak keys. you have to go out of your way to create a key that has so much zeros like this:
000000000000000000000000000000000000000000000000000efae164cb9e3c
even with broken RNG it is still impossible to get something like that!
additionally there are lots and addresses that are reused, meaning they have revealed their public key already. if it were possible to break anything they would have been broken already.
I wasn't suggesting that Bitcoin itself was vulnerable to pubkey->privkey attacks; this is the Bitcoin challenge thread, so of course we are talking about deliberately weak keys.
I think my suggestion still stands: if output #62 had been solved, but the fee was low, it's conceivable that someone else could have cracked the privkey before the transaction was incorporated into a block, then published their own transaction. It would be even easier for the lower range puzzle outputs.
I'm not a cryptographer, but the fact that you can crack a 62 bit key in a couple of hours IF you know the pubkey, versus "conceivably never" if you only know the RIPEMD160 hash of the pubkey, seems to suggest that the hashing does add a significant extra level of protection. Even accounting for 62 used bits being very weak when compared to 256.
Messed up privkeys are not impossible either. Creating a truly random private key is a fundamentally important part of Bitcoin, but I'm sure mistakes have been made, either by accident, or just through sloppy coding. Check out how mtgox lost 2609 BTC (not privkey related, but buggy coding related) :
https://bitcointalksearch.org/topic/someone-fucked-up-and-lost-alot-of-money-50206Imagine silly code like this:
#define KEY_LEN 8 /* 8 x 32 bits */
uint32_t key[KEY_LEN]; /* 32 bytes */
create_random_key(&key);
memcpy(somewhere_else, key, KEY_LEN); /* oops. only copies 8 bytes of key, instead of 32 */
And here's an example of where (I believe) a weak key was used in error: the key '7b7' (only 11 bits used) was sent 0.25 BTC a few months ago:
https://www.blockchain.com/btc/address/1FJJTKza3HovjzguAnMY9VYPu5Kd6CRKaI am guessing the sender was NOT intending to give away nearly $2k worth of BTC to a sweeper bot!
