<p><strong>The theory</strong></p>
<p>It is assumed that in order to forge an ECDSA signature you need to compute the private key for a given public key first (this operation is known as the &quot;discrete logarithm&quot; (DL), and its hardness is the basis for ECDSA's security). In order to do so, you must actually have the public key.</p>
<p>Once you have the public key, it is assumed that you need at least <em>2<sup>128</sup></em> operations to compute its private key. That's an enormous amount (if every computer in the world could do one relevant operation per clock cycle it would take over 100 million years; in reality it'd be orders of magnitude more than that). However, that is assuming that there are no fundamental breakthroughs in algorithms to compute the discrete logarithm, or quantum computers. A sufficiently powerful quantum computer (not anything anywhere near what already exists) may be able to do this computation <em>much</em> faster.</p>
<p>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. Barring any (spectacular) vulnerabilities found in the used hash functions (SHA256 and RIPEMD160), even a quantum computer cannot trivially find a public key from a hash function. However, the 160-bit hashes used are still considered relatively weak in this case (<em>2<sup>80</sup></em> operations on a sufficiently powerful quantum computer).</p>
<p>In short: the argument is that by using public key hashes, the ability for someone with a DL break, or a hypothetical quantum computer, to steal coins is made harder.</p>
<p><strong>In practice</strong></p>
<p>What I write in this section is my own opinion, and presumably not everyone agrees with it.</p>
<p>I believe this (often repeated) advantage of hashed public keys is marginal at best, and a false sense of security at worst. There are several reasons for this:</p>
<ul>
<li>The argument only applies until the output is (attempted to be) spent. Once someone tries to spend a pay-to-pubkey-hash output, they reveal the full public key. With minor cooperation from miners, the original transaction could be delayed temporarily to give the hypothetical quantum computing attacker time to find the private key and steal the coins.</li>
<li>Address reuse was, and still is, very common, and apparently hard to avoid. Whenever addresses are reused, their public key is revealed on the first spend, making all future ones vulnerable still.</li>
<li>Almost all interesting things that people do with Bitcoin (including multisig, 2FA, escrows, payment channels, BIP32 accounts, ...) involve sharing public keys with other parties. It's an illusion to think that in such a world any security is gained by using public key hashes - as public keys are revealed all the time still, often without people even knowing about it.</li>
<li>Even if you restrict yourself to carefully not rely on any of these techniques and keep all your public keys actually secret until spent, there are over 5 million BTC (my own <a href="https://twitter.com/pwuille/status/1108085284862713856" rel="noreferrer">research</a>) stored with <em>publicly</em> known public keys. I cannot imagine that BTC retains any value if those become practically vulnerable to theft (or even just credibly believed to be vulnerable).</li>
</ul>
<p>This doesn't mean we have a problem. Sufficiently powerful quantum computers are far away - if they're feasible at all for the enormous number of q-bits needed to solve these problems. This gives us time to slowly migrate to schemes that are actually quantum resistant (by not using ECDSA or similar cryptography at all). This is not yet done, as currently existing quantum-resistant schemes come with very large keys and signatures, and various other caveats. This makes them very unappealing fow now, but research on them is proceeding rapidly, and, if needed, they exist.</p>
<p><strong>Should you use public key addresses?</strong></p>
<blockquote>
<p>If one was writing a cryptocurrency would you advise against the addresses being the public key encoded in base58 with a checksum on the end? why?</p>
</blockquote>
<p>Advice on other cryptocurrencies is off-topic here, but the <a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki" rel="noreferrer">Taproot proposal</a> for Bitcoin would effectively do this. Its outputs (and thus addresses) contain a full public key, because it comes with numerous advantages (it's smaller, cheaper, and makes a number of more advanced protocols on top a lot easier).</p>
<p>The <a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki" rel="noreferrer">Bech32</a> 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, ...).</p>
<p>Disclaimer: I'm a co-author of both the Taproot proposal and the Bech32 standard.</p>
<p><strong>TL;DR: public keys should be <a href="https://twitter.com/benediktbuenz/status/1246895511652581376" rel="noreferrer">public</a>.</strong></p>

CC BY-SA 4.0
2020-04-05T19:56:07.600Z
2021-05-24T02:07:16.263Z
2021-05-24T02:07:16.263Z
Pieter Wuille
<p>According to <a href="https://bitcoin.stackexchange.com/a/3602/103172">this answer about why addresses are hashes rather than public keys</a> there are potential attacks that are possible if you have the public key rather than the address, what are these attacks? If one was writing a cryptocurrency would you advise against the addresses being the public key encoded in base58 with a checksum on the end? why?</p>

<address><public-key><ecdsa><attack>
What are the potential attacks against ECDSA that would be possible if we used raw public keys as addresses?
Leah Cornelius
# What are the potential attacks against ECDSA that would be possible if we used raw public keys as addresses?

(Asked by: username_0 on 2020-04-05)

According to [this answer about why addresses are hashes rather than public keys](https://bitcoin.stackexchange.com/a/3602/103172) there are potential attacks that are possible if you have the public key rather than the address, what are these attacks? If one was writing a cryptocurrency would you advise against the addresses being the public key encoded in base58 with a checksum on the end? why?

**Tags:** address, public-key, ecdsa, attack


---

## 1 answers

### Answer by username_1 on 2020-04-05. Score: 33 | Accepted answer

**The theory**

It is assumed that in order to forge an ECDSA signature you need to compute the private key for a given public key first (this operation is known as the "discrete logarithm" (DL), and its hardness is the basis for ECDSA's security). In order to do so, you must actually have the public key.

Once you have the public key, it is assumed that you need at least *2128* operations to compute its private key. That's an enormous amount (if every computer in the world could do one relevant operation per clock cycle it would take over 100 million years; in reality it'd be orders of magnitude more than that). However, that is assuming that there are no fundamental breakthroughs in algorithms to compute the discrete logarithm, or quantum computers. A sufficiently powerful quantum computer (not anything anywhere near what already exists) may be able to do this computation *much* 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. Barring any (spectacular) vulnerabilities found in the used hash functions (SHA256 and RIPEMD160), even a quantum computer cannot trivially find a public key from 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 for someone with a DL break, or a hypothetical quantum computer, to steal coins is made harder.

**In practice**

What I write in this section is my own opinion, and presumably not everyone agrees with it.

I believe this (often repeated) advantage of hashed public keys is marginal at best, and a false sense of security at worst. There are several reasons for this:

* The argument only applies until the output is (attempted to be) spent. Once someone tries to spend a pay-to-pubkey-hash output, they reveal the full public key. With minor cooperation from miners, the original transaction could be delayed temporarily to give the hypothetical quantum computing attacker time to find the private key and steal the coins.
* Address reuse was, and still is, very common, and apparently hard to avoid. Whenever addresses are reused, their public key is revealed on the first spend, making all future ones vulnerable still.
* Almost all interesting things that people do with Bitcoin (including multisig, 2FA, escrows, payment channels, BIP32 accounts, ...) involve sharing public keys with other parties. It's an illusion to think that in such a world any security is gained by using public key hashes - as public keys are revealed all the time still, often without people even knowing about it.
* Even if you restrict yourself to carefully not rely on any of these techniques and keep all your public keys actually secret until spent, there are over 5 million BTC (my own [research](https://twitter.com/pwuille/status/1108085284862713856)) stored with *publicly* known public keys. I cannot imagine that BTC retains any value if those become practically vulnerable to theft (or even just credibly believed to be vulnerable).

This doesn't mean we have a problem. Sufficiently powerful quantum computers are far away - if they're feasible at all for the enormous number of q-bits needed to solve these problems. This gives us time to slowly migrate to schemes that are actually quantum resistant (by not using ECDSA or similar cryptography at all). This is not yet done, as currently existing quantum-resistant schemes come with very large keys and signatures, and various other caveats. This makes them very unappealing fow now, but research on them is proceeding rapidly, and, if needed, they exist.

**Should you use public key addresses?**

> If one was writing a cryptocurrency would you advise against the addresses being the public key encoded in base58 with a checksum on the end? why?

Advice on other cryptocurrencies is off-topic here, but the [Taproot proposal](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) for Bitcoin would effectively do this. Its outputs (and thus addresses) contain a full public key, because it comes with numerous advantages (it's smaller, cheaper, and makes a number of more advanced protocols on top a lot easier).

The [Bech32](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki) 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, ...).

Disclaimer: I'm a co-author of both the Taproot proposal and the Bech32 standard.

**TL;DR: public keys should be [public](https://twitter.com/benediktbuenz/status/1246895511652581376).**


---

