<p>There are some other suggestions as to how this can be done without the "sign a message" feature coming in v0.5.
 - <a href="http://forum.bitcoin.org/index.php?topic=4411.0" rel="nofollow">http://forum.bitcoin.org/index.php?topic=4411.0</a></p>

<p>One suggestion was to receive a trivial but unique amount and then send that same amount back to the sender.  Awkward, but possible.</p>

CC BY-SA 3.0
2011-11-04T19:48:41.510Z
2011-11-04T19:48:41.510Z
Stephen Gornick
<p>The v0.5 client (still experimental as of time of writing) supports a function where you can sign a text message with a private key.  </p>

<p>So you could:
a) have a "register" button next to the address.
b) provide the user a message to sign which includes some identifying information (account name, email address, etc) and the address.
c) user will run bitcoind signmessage  ""
d) this will sign the message with user's private key.</p>

<p>Only a user which has access to the private key that corresponds to the address in question will be able to generate the correct signature.  Think of it as similar to a Bitcoin transaction but it isn't published to Bitcoin network and involves any text message.</p>

<p>Eligius uses this method to link NMC payment addresses to BTC payment addresses for his pool.</p>

<p><a href="http://eligius.st/" rel="noreferrer">http://eligius.st/</a></p>

<p>Obviously this will have more value once Bitcoind v0.05 is publicly released.</p>

CC BY-SA 3.0
2011-11-04T06:46:49.503Z
That is a cool feature. Is there also the "opposite" (encrypting a message with someone else's public key)? The public key cannot be derived from the bitcoin address, but it is included in the block chain once that address has been used, so such a function could be used to send confidential messages to someone that has sent you (or anyone) bitcoins before.
Thilo
CC BY-SA 3.0
2011-11-04T12:41:18.563Z
@Thilo I don't know if that functionality is currently included but if not there is no reason it couldn't be included in future version.  Signing a message is simply encrypting a hash of the message with the private key (so it can be decrypted w/ public key and verified).  If that can be done encrypting entire message w/ public key (so it can be decrypted w/ private key) is certainly possible.
DeathAndTaxes
CC BY-SA 3.0
2011-11-08T14:04:08.300Z
For RSA, it is true that signing equals "encrypting with the private key"; this is, however, not the case for DSA-based algorithms like ECDSA. Except for the wallet encryption added in v0.4.0, bitcoin does not employ encryption anywhere.
Pieter Wuille
CC BY-SA 3.0
2011-11-03T17:48:05.963Z
2011-11-03T17:48:05.963Z
DeathAndTaxes
<p>Lets say, I'd have a website that shows a large number of Bitcoin public addresses, and wanted to give option for anyone that owns a given address to verify it automatically.</p>

<p>Assuming that one shouldn't trust anyone on the internet based just on their word, how should one go about verifying that a person owns a given address? (methods that can run autonomously, without admin input, are preferred)</p>

<address><trust><verification><automation>
How should one try verifying to whom a given Bitcoin address belongs?
ThePiachu
# How should one try verifying to whom a given Bitcoin address belongs?

(Asked by: username_0 on 2011-11-03)

Lets say, I'd have a website that shows a large number of Bitcoin public addresses, and wanted to give option for anyone that owns a given address to verify it automatically.

Assuming that one shouldn't trust anyone on the internet based just on their word, how should one go about verifying that a person owns a given address? (methods that can run autonomously, without admin input, are preferred)

**Tags:** address, trust, verification, automation


---

## 2 answers

### Answer by username_2 on 2011-11-03. Score: 10 | Accepted answer

The v0.5 client (still experimental as of time of writing) supports a function where you can sign a text message with a private key.

So you could:
a) have a "register" button next to the address.
b) provide the user a message to sign which includes some identifying information (account name, email address, etc) and the address.
c) user will run bitcoind signmessage ""
d) this will sign the message with user's private key.

Only a user which has access to the private key that corresponds to the address in question will be able to generate the correct signature. Think of it as similar to a Bitcoin transaction but it isn't published to Bitcoin network and involves any text message.

Eligius uses this method to link NMC payment addresses to BTC payment addresses for his pool.

<http://eligius.st/>

Obviously this will have more value once Bitcoind v0.05 is publicly released.

> **Comments:**
> **username_3**: That is a cool feature. Is there also the "opposite" (encrypting a message with someone else's public key)? The public key cannot be derived from the bitcoin address, but it is included in the block chain once that address has been used, so such a function could be used to send confidential messages to someone that has sent you (or anyone) bitcoins before.  
> **username_2**: @username_3 I don't know if that functionality is currently included but if not there is no reason it couldn't be included in future version.  Signing a message is simply encrypting a hash of the message with the private key (so it can be decrypted w/ public key and verified).  If that can be done encrypting entire message w/ public key (so it can be decrypted w/ private key) is certainly possible.  
> **username_4**: For RSA, it is true that signing equals "encrypting with the private key"; this is, however, not the case for DSA-based algorithms like ECDSA. Except for the wallet encryption added in v0.4.0, bitcoin does not employ encryption anywhere.  

---

### Answer by username_1 on 2011-11-04. Score: 1

There are some other suggestions as to how this can be done without the "sign a message" feature coming in v0.5.
- <http://forum.bitcoin.org/index.php?topic=4411.0>

One suggestion was to receive a trivial but unique amount and then send that same amount back to the sender. Awkward, but possible.


---

