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.

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.

  • Is using a central authority acceptable? Jul 7 '18 at 23:14
  • 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
    Jul 8 '18 at 4:39

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

  • Excellent, @viktor-t! Thank you so much for providing that information. That is exactly what I was looking to accomplish. To be 100% certain here, are you saying that if someone were to somehow manage to intercept the transfer of the hashed public key and the signature, that they would be able to derive the public key from it?
    – Mike-E
    Jul 7 '18 at 16:37
  • 1
    Thanks! Happy I can help. Yes that is correct.
    – Viktor T.
    Jul 7 '18 at 16:48

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.

  • 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
    Jul 8 '18 at 6:47
  • @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. Jul 9 '18 at 0:42
  • Great, I am with you now, @DavidSchwartz. In my case, I am considering the support for both centralized and decentralized scenarios, allowing the user to select which they prefer and/or trust more. Knowing this approach allows me to move towards doing exactly that. Thank you for the clarification and providing awareness around this for myself and others who are also learning this field.
    – Mike-E
    Jul 9 '18 at 15:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.