The typical way to spend btc is to lock them to a receiving address which is a 160-bit representation of a 256 bit ECDSA script.  In theory, couldn't an attacker present a different pubkey and  a signed message to redeem coins on an address which happens to hash to the same address as the legit owner?  Wouldn't the odds of this collision be 2^160  (yes yes thats A LOT of keys to generate) but its not 2^256 now is it?

Additionally, lets assume there are 65k addresses worth stealing from, i'll steal from any of these (2^16).  Doesn't that now reduce the number of hashes i'd have to go through to 2^144?

Its still a poopload of key pairs to generate, my guess is only a few hundred or few thousand could be iterated/sec on a standard pc.

But this raises the question:  why didn't satoshi use sept160k1 which would have pubkeys of only 40+ digit hex (corresponding to the strength of ripemd160), instead of 64+ digit hex for sepc256? 

Again, in theory we can reduces the 2^256 sets of key pairs to just 2^160, cuz as I get it, to spend a balance you only have to show a pubkey which ripemd160 hashes to the receiving address.

Did i miss something or is the ECDSA really just 160 (or 144) bit strong?