<p>1) Generate a random private key just to be used to prove ownership.  </p>

<p>2) Create a message with the corresponding public key to the key generated in step one and the public key you wish to prove ownership of.  </p>

<p>3) Sign it with both private keys.  </p>

<p>4) Send it to a central authority.  </p>

<p>5) Receive from the central authority a signed statement saying that the owner of the public key corresponding to the private key you generated in step 1 belongs to the account you wish to prove ownership of.  </p>

<p>6) You can now use the key you generated in step 1 to prove ownership of the account without revealing the account's public key to anyone since the signed statement from the central authority binds the key you generated in step 1 to the account, proving common control.</p>

CC BY-SA 4.0
2018-07-08T06:47:50.670Z
Alright I _think_ I have my head mostly wrapped around this, @david-schwartz. Thank you for providing this workflow.  My confusion is in the 2nd step.  Should that read "and the public key _hash_ you wish to prove ownership of."?  If the user is sending the public key of the account in question, they are still using their public key to prove ownership of a hashed address, which is what I am trying to avoid.  Or, is the implication/assumption here that this signed statement is to be stored somewhere by the user for use at a later date such as this scenario?
Mike-E
CC BY-SA 4.0
2018-07-09T00:42:13.733Z
@Mike-EEE The user has to provide their public key to the central authority, otherwise the central authority can't check the signature on the request. But when providing proof to others, they can just use the statement from the authority without having to disclose the public key.
David Schwartz
CC BY-SA 4.0
2018-07-08T04:47:46.777Z
2018-07-08T04:47:46.777Z
David Schwartz
<p>The simple answer is no.</p>

<p>A hashing algorithm is ment to be a one-way function. If it is possible to recreate the public key from the hash, this means that the hashing algorithm is broken. </p>

<p>However there is one aspect that you might find useful. For message signatures, bitcoin uses a custom encoding (compared to the DER encoded signature found in transactions). </p>

<p>Given a custom encoded message signature, the message and a public key hash, you can verify that the signature is correct. However, <strong>please note</strong> that this is because the custom encoded signature supports public key recovery. Therefore this results in the same security aspects as just supplying the public key, but with the benefit that the user does not need to specifically transfer the public key to you.  </p>

<p>If you would like to test the custom encoded signatures, they are returned by the "signmessage" function in the bitcoin core client. They can then be verified by the "verifymessage" function, or by multiple online tools, such as this one:
<a href="https://blockexplorer.com/messages/verify" rel="noreferrer">https://blockexplorer.com/messages/verify</a></p>

CC BY-SA 4.0
2018-07-07T16:21:28.000Z
2018-07-07T17:21:13.617Z
2018-07-07T17:21:13.617Z
user44404
<p>I am building a system where I would like the user to specify a public key hash of a wallet that they have control over in the event of tips, refunds, and/or otherwise needing to send value back to them.</p>

<p>From there, I would like to further provide a feature that lets the user <em>verify</em> that they own this hashed address.</p>

<p>If I understand correctly, they can prove this by signing a message that I send them, and then they could send the signature back to me along with the public key.</p>

<p>However, I also understand that exposing your public key is considered <a href="https://crypto.stackexchange.com/a/48433">less than ideal</a>.</p>

<p>So, I am curious if there is some solution somewhere that will allow me to verify ownership based on the hashed address alone, without the use of a public key.</p>

<p>I suppose that since this verification process is transient and will not be permanently stored in a public blockchain (or anywhere else), it is not as potentially harmful of a scenario (or rather, more "trustworthy" for the user).  However, I am wanting to be as mindful to their privacy and security as possible and provide them with the opportunity to verify their ownership to this hashed address in the least invasive way available.</p>

<p>Is it enough to simply state somewhere in the user interface that this verification process will not store the public key in any way?  This is all assuming a HTTPS connection, but of course the risk is that since bad actors will know that public keys are being transmitted, it opens up one more <em>potential</em> vector of possible attack.</p>

<p>Also, I am very much interested in other approaches that are preferred/known here, as well as any examples of other sites and/or services that have tackled this problem in an elegant way.</p>

CC BY-SA 4.0
2018-07-07T23:14:02.753Z
Is using a central authority acceptable?
David Schwartz
CC BY-SA 4.0
2018-07-08T04:39:51.230Z
Sure @DavidSchwartz, please feel free to share.  I am new to this space and am interested in learning different approaches.  As this will be my first project it will probably have a hybrid approach to get my feet under me, so some elements will be central.
Mike-E
<privacy><public-key><wallet-security><message-signing><security-key>
Is It Possible to Prove Ownership of Public Key Hash without Public Key?
Mike-E
# Is It Possible to Prove Ownership of Public Key Hash without Public Key?

(Asked by: username_0 on 2018-07-07)

I am building a system where I would like the user to specify a public key hash of a wallet that they have control over in the event of tips, refunds, and/or otherwise needing to send value back to them.

From there, I would like to further provide a feature that lets the user *verify* that they own this hashed address.

If I understand correctly, they can prove this by signing a message that I send them, and then they could send the signature back to me along with the public key.

However, I also understand that exposing your public key is considered [less than ideal](https://crypto.stackexchange.com/a/48433).

So, I am curious if there is some solution somewhere that will allow me to verify ownership based on the hashed address alone, without the use of a public key.

I suppose that since this verification process is transient and will not be permanently stored in a public blockchain (or anywhere else), it is not as potentially harmful of a scenario (or rather, more "trustworthy" for the user). However, I am wanting to be as mindful to their privacy and security as possible and provide them with the opportunity to verify their ownership to this hashed address in the least invasive way available.

Is it enough to simply state somewhere in the user interface that this verification process will not store the public key in any way? This is all assuming a HTTPS connection, but of course the risk is that since bad actors will know that public keys are being transmitted, it opens up one more *potential* vector of possible attack.

Also, I am very much interested in other approaches that are preferred/known here, as well as any examples of other sites and/or services that have tackled this problem in an elegant way.

**Tags:** privacy, public-key, wallet-security, message-signing, security-key

> **Comments:**
> **username_1**: Is using a central authority acceptable?  
> **username_0**: Sure @username_1, please feel free to share.  I am new to this space and am interested in learning different approaches.  As this will be my first project it will probably have a hybrid approach to get my feet under me, so some elements will be central.  

---

## 2 answers

### Answer by username_2 on 2018-07-07. Score: 6 | Accepted answer

The simple answer is no.

A hashing algorithm is ment to be a one-way function. If it is possible to recreate the public key from the hash, this means that the hashing algorithm is broken.

However there is one aspect that you might find useful. For message signatures, bitcoin uses a custom encoding (compared to the DER encoded signature found in transactions).

Given a custom encoded message signature, the message and a public key hash, you can verify that the signature is correct. However, **please note** that this is because the custom encoded signature supports public key recovery. Therefore this results in the same security aspects as just supplying the public key, but with the benefit that the user does not need to specifically transfer the public key to you.

If you would like to test the custom encoded signatures, they are returned by the "signmessage" function in the bitcoin core client. They can then be verified by the "verifymessage" function, or by multiple online tools, such as this one:
<https://blockexplorer.com/messages/verify>


---

### Answer by username_1 on 2018-07-08. Score: 3

1) Generate a random private key just to be used to prove ownership.

2) Create a message with the corresponding public key to the key generated in step one and the public key you wish to prove ownership of.

3) Sign it with both private keys.

4) Send it to a central authority.

5) Receive from the central authority a signed statement saying that the owner of the public key corresponding to the private key you generated in step 1 belongs to the account you wish to prove ownership of.

6) You can now use the key you generated in step 1 to prove ownership of the account without revealing the account's public key to anyone since the signed statement from the central authority binds the key you generated in step 1 to the account, proving common control.

> **Comments:**
> **username_0**: Alright I _think_ I have my head mostly wrapped around this, @username_1-username_1. Thank you for providing this workflow.  My confusion is in the 2nd step.  Should that read "and the public key _hash_ you wish to prove ownership of."?  If the user is sending the public key of the account in question, they are still using their public key to prove ownership of a hashed address, which is what I am trying to avoid.  Or, is the implication/assumption here that this signed statement is to be stored somewhere by the user for use at a later date such as this scenario?  
> **username_1**: @Mike-EEE The user has to provide their public key to the central authority, otherwise the central authority can't check the signature on the request. But when providing proof to others, they can just use the statement from the authority without having to disclose the public key.  

---

