No, because the Bitcoin address is RIPEMD160(SHA256(pubkey)), with some additional protocol things tacked onto it. If you can find some reduction of SHA256 to RIPEMD160 such that you can recover any SHA256 preimage more or less for free from the RIPEMD160 preimage, then it would be 160-bit equivalent security. The 128-bit number comes from dividing 256 by two on the assumption that the best way to brute-force a Bitcoin address with a QC is to break the RIPEMD160 (I'm counting this as zero-cost) and then break the SHA256 (I'm counting this as 256-bit / 2 security = 128-bits security).
I think I see what you mean. I got wrong what I said in my nit; but I now have another. Please correct me if I messed up something else here; I think that breaking a keyhash found on blockchain would require the following steps, in this order:
0. Its impossible to recover 256 bits of pseudorandom anything from 160 pigeonholes; so I will infer that to be, find any
P0 of the many 256-bit preimages for a given RIPEMD160 hash. With a quantum computer, consider that to be the equivalent of an 80-bit problem. Not what I would call zero.
Approximately 2
96 SHA256 outputs map to each RIPEMD160 output (by the pigeon-hole principle). But the attack complexity of recovering the SHA256 preimage (the pubkey) is still 2
256 bits of security. In other words, the RIPEMD160 step does not reduce the security of the system against recovering the pubkey. However, it does reduce the complexity of substituting another pubkey in its place (second preimage security) since you "only" have to search an average of 2
159 pubkeys to find one whose SHA256 hash collides with the RIPEMD160 hash:
RIPEMD160(SHA256(my_key)) = RIPEMD160(SHA256(attackers_key)) <-- brute-forcing this "only" requires 2
159 attempts on average
Now, you can reduce the complexity further by only attempting public keys with valid private keys (2
128 or so):
RIPEMD160(SHA256(priv_to_pub(my_priv_key))) = RIPEMD160(SHA256(priv_to_pub(attackers_priv_key))) <-- brute-forcing this "only" requires 2
127 attempts on average, however, priv_to_pub() is a very computationally expensive operation.
2. Wield the almighty Quantum Computer to break the public keythus revealing a private key which can spend for a public key which SHA256 hashes to a bitstring which hashes to the RIPEMD160 hash specified in the Bitcoin output. Breaking the public key would still not be free. I dont know how to quantify that in bits of security.
SoI see the equivalent of 208+x bits of quantum computer work. Did I get it right here?
I think it's still about 128 bits search space because there are about 2
128 valid secp256k1 private keys. However, since there are 2
160 possible addresses, we are not guaranteed to find a collision - it is possible that a given secp256k1 private key has no other colliding Bitcoin address. But since it is a (pseudo)-random mapping, there are surely collisions (birthday paradox). If a given private key and its associated address have no collisions, the search time (not average) is 2
160 (you must exhaust all addresses to be sure); if 1 collision the average search time to find it is 2
159; if 2 collisions, the average search time is greater than 2
158; if 4 it is 2
158, and so on. I'm sure this could be written out as a sum using sigma notation if a person was determined to do so.
Endpoint security is so awful
Don't get me started...