It is assumed that to forge an ECDSA signature, you must first calculate the private key for a given public key (this operation is known as "discrete logarithm" (DL), and its hardness is the basis of ECDSA security). To do this, you must actually have the public key.
Once you have the public key, it is assumed that you need at least 2128 to calculate his private key. It is huge (if every computer in the world could perform a relevant operation per clock cycle, it would take more than 100 million years; in reality, it would be orders of magnitude more than that ). However, this assumes that there are no fundamental breakthroughs in the algorithms for calculating the discrete logarithm or quantum computers. A sufficiently powerful quantum computer (not anything close to what already exists) may be able to do this calculation many faster.
By using an address that contains a hash of the public key rather than the public key directly, the actual public key is not revealed to the world until the output is spent by its owner. With the exception of the (spectacular) vulnerabilities found in the hash functions used (SHA256 and RIPEMD160), even a quantum computer cannot trivially find a public key in a hash function. However, the 160-bit hashes used are still considered relatively weak in this case (280 operations on a sufficiently powerful quantum computer).
In short: the argument is that by using public key hashes, the ability of a person with a DL break or a hypothetical quantum computer to steal coins is made more difficult.
What I write in this section is my own opinion, and not everyone probably agrees with it.
I believe that this (often repeated) advantage of chopped public keys is marginal at best and at worst a false sense of security. There are several reasons for this:
- The argument only applies until the exit is (tempted to be) spent. Once someone tries to spend a pay-to-pubkey hash output, it reveals the full public key. With minor co-operation from miners, the original transaction could be temporarily delayed to give the hypothetical quantum computer attacker time to find the private key and steal the coins.
- Address reuse was, and still is, very common and seemingly difficult to avoid. Each time the addresses are reused, their public key is revealed during the first expenditure, making all future ones still vulnerable.
- Almost all of the interesting things that people do with Bitcoin (including multisig, 2FA, escrows, payment channels, BIP32 accounts, …) involve sharing public keys with other parties. It is an illusion to think that in such a world, all security is gained by using public key hashes – because public keys are always revealed, often without people knowing it.
- Even if you limit yourself to not relying on any of these techniques and keeping all of your public keys secret until you use them, there are more than 5 million BTCs (mine research) stored with publicly known public keys. I cannot imagine that BTC retains a value if these become practically vulnerable to theft.
This does not mean that we have a problem. Sufficiently powerful quantum computers are far – if they are achievable for the huge number of q-bits needed to solve these problems. This gives us time to slowly migrate to patterns that are actually quantum resistant (not using ECDSA or similar cryptography at all). This has not yet been done, as the current quantum resistance patterns come with very large keys and signatures, and various other caveats. This makes them very unattractive now, but research on them is advancing rapidly and, if necessary, they exist.
Should you use public key addresses?
If writing a cryptocurrency, would you not recommend that the addresses be the public key encoded in base58 with a checksum at the end? Why?
Advice on other cryptocurrencies is irrelevant here, but the Taproot proposal for Bitcoin would actually do that. Its outputs (and therefore its addresses) contain a complete public key, because it has many advantages (it is smaller, cheaper and makes a number of more advanced protocols much easier).
The Bech32 address format is used for these types of outputs, which has a number of advantages over Base58 (easier to transliterate / compare, stronger error detection, more extensible , smaller QR codes, …).
Warning: I am co-author of the Taproot proposal and the Bech32 standard.
TL; DR: public keys must be Public.