<p>You could really use any address for that matter, as long as whatever address you choose + the message itself + the verification signature are all the same. </p>

<p>So it doesn't prove that your the owner of the address, it just proves that message you sent is the one you expect the receiver to be able to verify. Seems a bit useless to be frank.</p>

CC BY-SA 3.0
2015-04-05T05:33:13.410Z
`So it doesn't prove that your the owner of the address` What? It definitely does. If not, I challenge you to prove that you own `1snowqqp5vmzgu47i5awwz9fsghqg94fa`.
Nick ODell
CC BY-SA 3.0
2016-05-12T13:25:28.947Z
"You could really use any address for that matter" Nope, you can only use an address you have the private key for. i.e. an address you control/own.
occulus
CC BY-SA 4.0
2022-11-15T19:35:22.193Z
You can't get the signing key from the verifying key, let alone the RIPEMD-160 hash of the SHA-256 hash of the verifying key. You absolutely need the private key to be able to sign a message.
Tyler Pantuso
CC BY-SA 3.0
2015-04-04T15:23:49.737Z
2015-04-04T15:23:49.737Z
Ron Deline
<p>The signing mechanism is a way of proving that a particular message was signed by the holder of an address' private key.  A merchant could ask that you sign a message stating where you want your order shipped to, using one of the addresses your payment originated from.</p>

<p>You should sign a statement saying "I, Jane Doe (jane.doe@email.com) sent 1.23 BTC to Acme Corp at 12:34pm, 1st Jan 2012 in payment for product XYZ for delivery to 456 High Street, Anytown, USA".</p>

<p>You shouldn't sign a vague statement saying "yes, I sent that money; send the product to the address I emailed you", because anyone seeing a copy of that signed message can then pass that on to the merchant with his own postal address and get the product you paid for, in the same way as you wouldn't put your signature to a piece of paper saying "I agree to the above" where the above was left blank.  The postal address part won't be signed, but perhaps the merchant won't care.</p>

CC BY-SA 3.0
2012-04-01T12:28:09.883Z
Additionally, it's a good idea to add: a) who you (the sender) are (name, customer id, email, ...), b) who it is intended for (business name, ...) c) time and date.
Pieter Wuille
CC BY-SA 3.0
2012-04-01T18:57:00.957Z
If you're really, really paranoid, you can include the transaction ID as well.
David Schwartz
CC BY-SA 3.0
2012-06-06T04:09:34.090Z
while this question is here, let me piggyback and ask for comments on signing one-time nonce values (as is currently implemented for #bitcoin-otc signmessage authentication). Any thoughts on that? it has been proposed by luke that even nonce values shouldn't be signed, without accompanying readable text stating what it is for and a timestamp. Is that a reasonable precaution to take, or are attacks on that pretty far-out in paranoia-land?
nanotube
CC BY-SA 3.0
2012-06-11T02:42:41.493Z
"Hi, I want to cancel <Joe's order> and get my refund sent to <nanotube's address>. Here is a token signed to prove I am Joe: <Joe's #bitcoin-otc auth>"

Even if we trust you specifically, it sets a bad precedent for people to sign/accept these.
Luke Dashjr
CC BY-SA 3.0
2012-06-11T03:46:11.473Z
luke: well, that can be done regardless of the content of the signed message. even if it is of the form "DATE, authenticating joe on #bitcoin-otc, NONCE", i can take it and say "hey here's a token signed to prove i'm joe".
nanotube
CC BY-SA 3.0
2012-04-01T05:15:21.347Z
2012-04-01T17:00:56.277Z
2012-04-01T17:00:56.277Z
Chris Moore
<p>bitcoin-qt's dialog box states, "Be careful not to sign anything vague, as phishing attacks may try to trick you into signing your identity over to them. Only sign fully-detailed statements you agree to."</p>

<p>What would this kind of attack look like?  What are some examples of statements that would be safe to sign agreement to?</p>

<security><bitcoin-core><message-signing>
What are the safety guidelines for using the Sign Message feature?
osmosis
# What are the safety guidelines for using the Sign Message feature?

(Asked by: username_0 on 2012-04-01)

bitcoin-qt's dialog box states, "Be careful not to sign anything vague, as phishing attacks may try to trick you into signing your identity over to them. Only sign fully-detailed statements you agree to."

What would this kind of attack look like? What are some examples of statements that would be safe to sign agreement to?

**Tags:** security, bitcoin-core, message-signing


---

## 2 answers

### Answer by username_5 on 2012-04-01. Score: 25 | Accepted answer

The signing mechanism is a way of proving that a particular message was signed by the holder of an address' private key. A merchant could ask that you sign a message stating where you want your order shipped to, using one of the addresses your payment originated from.

You should sign a statement saying "I, Jane Doe (jane.doe@email.com) sent 1.23 BTC to Acme Corp at 12:34pm, 1st Jan 2012 in payment for product XYZ for delivery to 456 High Street, Anytown, USA".

You shouldn't sign a vague statement saying "yes, I sent that money; send the product to the address I emailed you", because anyone seeing a copy of that signed message can then pass that on to the merchant with his own postal address and get the product you paid for, in the same way as you wouldn't put your signature to a piece of paper saying "I agree to the above" where the above was left blank. The postal address part won't be signed, but perhaps the merchant won't care.

> **Comments:**
> **username_6**: Additionally, it's a good idea to add: a) who you (the sender) are (name, customer id, email, ...), b) who it is intended for (business name, ...) c) time and date.  
> **username_7**: If you're really, really paranoid, you can include the transaction ID as well.  
> **username_8**: while this question is here, let me piggyback and ask for comments on signing one-time nonce values (as is currently implemented for #bitcoin-otc signmessage authentication). Any thoughts on that? it has been proposed by username_9 that even nonce values shouldn't be signed, without accompanying readable text stating what it is for and a timestamp. Is that a reasonable precaution to take, or are attacks on that pretty far-out in paranoia-land?  
> **username_9**: "Hi, I want to cancel <Joe's order> and get my refund sent to <username_8's address>. Here is a token signed to prove I am Joe: <Joe's #bitcoin-otc auth>"  Even if we trust you specifically, it sets a bad precedent for people to sign/accept these.  
> **username_8**: username_9: well, that can be done regardless of the content of the signed message. even if it is of the form "DATE, authenticating joe on #bitcoin-otc, NONCE", i can take it and say "hey here's a token signed to prove i'm joe".  

---

### Answer by username_1 on 2015-04-04. Score: 0

You could really use any address for that matter, as long as whatever address you choose + the message itself + the verification signature are all the same.

So it doesn't prove that your the owner of the address, it just proves that message you sent is the one you expect the receiver to be able to verify. Seems a bit useless to be frank.

> **Comments:**
> **username_2**: `So it doesn't prove that your the owner of the address` What? It definitely does. If not, I challenge you to prove that you own `1snowqqp5vmzgu47i5awwz9fsghqg94fa`.  
> **username_3**: "You could really use any address for that matter" Nope, you can only use an address you have the private key for. i.e. an address you control/own.  
> **username_4**: You can't get the signing key from the verifying key, let alone the RIPEMD-160 hash of the SHA-256 hash of the verifying key. You absolutely need the private key to be able to sign a message.  

---

