Can someone explain the "Sign message" feature in QT 0.6.0.4?

[michaelmclees]

Can someone explain how to verify a signed message created by the new Bitcoin client?  Is the idea that I can prove ownership of a wallet by pasting the encrypted message and giving out my address?

Like, someone might say, "OK, prove that you own the address 1PBEkptWgC4JqmJjT8BrbG414H9X9ezgUW."

And I respond with, "Here is proof...  G4trPovqJNoMvk0NjdHkTyZG/piN5f12bFlS5NA9LhqyGJRZFbNuqMUw/wc3HUeiwgKV2WXuyk9JBAEL3CPTqOI=" which translates to "Yes.  I do own this address.  1PBEkptWgC4JqmJjT8BrbG414H9X9ezgUW", but only if indeed I do own the address in question.

Do I have this right?  Is this how it works?

If so, how does the person requesting verification actually do that?

[1714176462]

1714176462

[1714176462]

1714176462

[1714176462]

1714176462

[1714176462]

1714176462

[stevegee58]

I was wondering this myself.  The sign operation isn't much use without a verify.

[DeepBit]

Like, someone might say, "OK, prove that you own the address 1PBEkptWgC4JqmJjT8BrbG414H9X9ezgUW."

No, it's the opposite.
They can check if this message was created by you if they know that this is your address.

[michaelmclees]

Like, someone might say, "OK, prove that you own the address 1PBEkptWgC4JqmJjT8BrbG414H9X9ezgUW."

No, it's the opposite.
They can check if this message was created by you if they know that this is your address.

How do they do this?

[mcorlett]

Via the JSON-RPC API:

Code:

verifymessage [address] [signature] [message]

[stevegee58]

Just seems odd they added signing to the GUI but not verify.

[Diapolo]

Just seems odd they added signing to the GUI but not verify.

I'm sure this will follow ... seems like only an GUI issue, if the RPC command is in.

Dia

[etotheipi]

FYI: I have added a message signing and verification interface into Armory, as part of the the ECDSA calculator.   The interface is a little weird, because it was merged with a privatekey/publickey/address calculator, but it is very functional.

Why is this useful?
It's not so much for "verifying ownership of a wallet," but it is a good way to send messages that the receiver can verify came from the owner of an address.  Here's a couple excellent uses for it:

• You purchase something online for 1,000 BTC and the seller needs a shipping address.  Send them a signature block with your shipping address via email, signed with one of the addresses you used to pay them.  They know it must've come from the same person who paid them, which is the only important part.  No one can spoof an email from you to have them ship it somewhere else.
• If this functionality had existed at the time, it would've been a brilliant way for MtGox to verify users' accounts after the hacking last year!  All they had to do was send out emails saying "Account #0582921 was originally funded with address 1Ahgk48sfQz.  Please provide your name, address, and Dwolla acct number in a signed message by Bitcoin address 1Ahgk48sfQz to claim ownership."  Again, the only person that can provide such a message, must be the same person that originally funded the account!
• Expanding on the Mt.Gox idea:  services can start using this for anonymous account management, especially online gambling.  A user funds an online gambling account completely anonymously using Bitcoins.  Then, they decide they want move money around, buy stuff, play big games, or cash out to a different address.  The only requirement for doing so is that they make the request using a signature block signed with the very first address that ever funded the account.  They never have to identify their own name, address, make any kind of account login&password, password recovery, not even email address!  All that matters is that the same person who funded the account, is the person making the current request!

To Sign a Message with Armory (works fine in offline mode):

• Open Armory, go to the menu, "Tools"-->"Message Signing"
• Put your address into the "Bitcoin Address" box.  If this key is yours, a message will pop up saying "This key is in one of your wallets!".
• Type in your message into the message box.  You can use the buttons to insert random hex characters, or the current datetime.  The only restriction is to not use any newlines in the message.
• Click "Get keys from Wallet" at the top of the window to pull in your private key for signing. (I will remove this step in the next version, it's unnecessary)
• Click the "Sign Message" button which will dump a raw signature in the box to the right.
• Click the "Create Signature Block" button which will copy the signature block to the clipboard.  
• You can test it by clicking "Import Signature Block" and pasting the clipboard into it.  You will see what the verification window looks like.
• Send the signature block in an email or pastebin.

To Verify a Signature Block with Armory (works fine in offline mode):

• Open Armory, go to the menu, "Tools"-->"Message Signing"
• Click on "Import Signature Block" at the bottom of the screen.
• Paste the signature block, and click "Okay"
• Address will be checked against public key, public key checked against signature for the given message

None of this requires the blockchain, so if you are on a system that couldn't normally run Armory, you only need to run with the "--noblockchain" option.  This allows you to verify Armory signature blocks without even having an Armory wallet!  If you're intrigued, try this one:  (get Armory if necessary)

Code:

-----BEGIN-SIGNATURE-BLOCK-------------------------------------
Address:    1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv
Message:    "Armory version 0.60-alpha was released 2012-Mar-"
            "19 07:40pm. Windows binaries have been released "
            "in zip files with the following MD5 hashes:  [Wi"
            "n32::7b6e3dd0e9114523e303db304a87c0d6] [Win64::e"
            "930159411483428da40c127f654bf69] Please do not u"
            "se any zip files whose hash values do not match!"
PublicKey:  0411d14f8498d11c33d08b0cd7b312fb2e6fc9aebd479f8e9a
            b62b5333b2c395c5f7437cab5633b5894c4a5c2132716bc36b
            7571cbe492a7222442b75df75b9a84
Signature:  842590674c06b8712bd9aa04ae7e3fd4c09410f6881ec5a361
            fcab55433f1d28f569b3771216754f400a5674e24984943d62
            9079a8d56b3c5285ee533f8f4f16
-----END-SIGNATURE-BLOCK---------------------------------------

Btw, these signatures are not compatible with the Satoshi client signatures.  I will make an effort to synchronize them later after RAM-reduction.

P.S. - This works with offline wallets, too, since it doesn't require the blockchain.  Just get on your offline computer, create the signature block as above, and copy it to a USB key to take to the online computer.  It's even easier than an offline transaction because you can start on the offline computer and only need to move data one direction.

[FreeMoney]

If this functionality had existed at the time, it would've been a brilliant way for MtGox to verify users' accounts after the hacking last year!  All they had to do was send out emails saying "Account #0582921 was originally funded with address 1Ahgk48sfQz.  Please provide your name, address, and Dwolla acct number in a signed message by Bitcoin address 1Ahgk48sfQz to claim ownership."  Again, the only person that can provide such a message, must be the same person that originally funded the account!

That isn't failproof, people use Gox or any wallet to receive payments from others. I guess that's why you mention the dwolla number, but some people won't have a dwolla number and in some cases an attacker could have been paying a person dwolla and then switched to paying them coin straight into Gox.

Also a webwallet or service provider would have a lot of "other people's" keys.

[etotheipi]

If this functionality had existed at the time, it would've been a brilliant way for MtGox to verify users' accounts after the hacking last year!  All they had to do was send out emails saying "Account #0582921 was originally funded with address 1Ahgk48sfQz.  Please provide your name, address, and Dwolla acct number in a signed message by Bitcoin address 1Ahgk48sfQz to claim ownership."  Again, the only person that can provide such a message, must be the same person that originally funded the account!

That isn't failproof, people use Gox or any wallet to receive payments from others. I guess that's why you mention the dwolla number, but some people won't have a dwolla number and in some cases an attacker could have been paying a person dwolla and then switched to paying them coin straight into Gox.

Also a webwallet or service provider would have a lot of "other people's" keys.

Gah, I keep forgetting that "web wallets" exist.  I've never used one because I never understood why I'd have another service hold my money when the regular Bitcoin client seemed simple enough to use...? 

So, the concept still works but only if the agreement starts out that way.  It could be a prerequisite that, in order to use a certain online gambling site, that you must fund the account yourself and be able to sign messages with that original address.  Or, there's an option when you start an account "I will create a login & password / I will use the first funding address as my identity."

[michaelmclees]

Cool.  I think I get it now.

[FreeMoney]

If this functionality had existed at the time, it would've been a brilliant way for MtGox to verify users' accounts after the hacking last year!  All they had to do was send out emails saying "Account #0582921 was originally funded with address 1Ahgk48sfQz.  Please provide your name, address, and Dwolla acct number in a signed message by Bitcoin address 1Ahgk48sfQz to claim ownership."  Again, the only person that can provide such a message, must be the same person that originally funded the account!

That isn't failproof, people use Gox or any wallet to receive payments from others. I guess that's why you mention the dwolla number, but some people won't have a dwolla number and in some cases an attacker could have been paying a person dwolla and then switched to paying them coin straight into Gox.

Also a webwallet or service provider would have a lot of "other people's" keys.

Gah, I keep forgetting that "web wallets" exist.  I've never used one because I never understood why I'd have another service hold my money when the regular Bitcoin client seemed simple enough to use...? 

So, the concept still works but only if the agreement starts out that way.  It could be a prerequisite that, in order to use a certain online gambling site, that you must fund the account yourself and be able to sign messages with that original address.  Or, there's an option when you start an account "I will create a login & password / I will use the first funding address as my identity."

Sure, it does work with that caveat. BitLotto works on that assumption and even tells users which webwallets are ok.

It's probably a good standard to have keys assigned to accounts and even blind the site administration to them, iiuc blockchain.info does that.

[etotheipi]

Gah, I keep forgetting that "web wallets" exist.  I've never used one because I never understood why I'd have another service hold my money when the regular Bitcoin client seemed simple enough to use...? 

So, the concept still works but only if the agreement starts out that way.  It could be a prerequisite that, in order to use a certain online gambling site, that you must fund the account yourself and be able to sign messages with that original address.  Or, there's an option when you start an account "I will create a login & password / I will use the first funding address as my identity."

Sure, it does work with that caveat. BitLotto works on that assumption and even tells users which webwallets are ok.

It's probably a good standard to have keys assigned to accounts and even blind the site administration to them, iiuc blockchain.info does that.

The webwallet could have a page providing the exact same interface as Armory has:  "Enter your message and it will be signed by the specified private key."  And a button for "copy signature block to clipboard."  It would be trivial to add, since it already uses your private keys to send money. 

The big issue is how to handle stolen wallets... and maybe this condition would defeat the purpose of the whole exercise:  if they have to resort to secondary verification methods because message signing isn't reliable, then did the message-signing provide any valuee?  I'm sure there's still plenty of useful applications.

[Haplo]

If you put your coins through some sort of anonymizing system that mixes them up, isn't it basically impossible for the recipient to track what address the coins were sent from?

If that's the case, then wouldn't validation via signature be impractical, or at the very least require some breach of anonymity?

[bitlotto]

If you put your coins through some sort of anonymizing system that mixes them up, isn't it basically impossible for the recipient to track what address the coins were sent from?

If that's the case, then wouldn't validation via signature be impractical, or at the very least require some breach of anonymity?

It could work...
-user asks to deposit BTC into the service and provides a Bitcoin address for signing messages (new address that's never been used)
-service provides an address for depositing BTC
-the service provider keeps a list of deposit address/signing address/amount
-once the deposit address is funded they can delete the record of the deposit address
-whenever someone signs a message with the signing address they can release the funds to whatever address they specify
-this limits the time that a record exists linking the old address with the new one
You would still have to trust that the operator does in fact delete that link though.

[Haplo]

If you put your coins through some sort of anonymizing system that mixes them up, isn't it basically impossible for the recipient to track what address the coins were sent from?

If that's the case, then wouldn't validation via signature be impractical, or at the very least require some breach of anonymity?

It could work...
-user asks to deposit BTC into the service and provides a Bitcoin address for signing messages (new address that's never been used)
-service provides an address for depositing BTC
-the service provider keeps a list of deposit address/signing address/amount
-once the deposit address is funded they can delete the record of the deposit address
-whenever someone signs a message with the signing address they can release the funds to whatever address they specify
-this limits the time that a record exists linking the old address with the new one
You would still have to trust that the operator does in fact delete that link though.

Yeah, nevermind that. I figured it out after reading another thread on anonymity. It's a bit complicated as-is, and it's difficult to scramble your coins between your primary funding addresses and your one-offs or special addresses (such as an addy for linking to a bank account). I'm not even sure if there are any services for doing this, although there's some talk of possible techniques on the dev list.

[etotheipi]

Why can't you use the mixing service to fund the same address that will be funding the account? 

-- Service provides address, A, to which you want to deposit 20 BTC
-- Create new address, B
-- Send 20 BTC from your regular wallet to the mixer, to be sent to B
-- Send 20 BTC from B to A (through Tor)
-- B is now your permanent identity with that service:  use signed messages to communicate actions.

It's an extra hop, but it maintains the anonymity, because B is used exactly once and never linked to any other address.  And the service doesn't know anything beyond that address B sent 20 BTC and is now empty.  Then you don't have to do anything with the service other than send them money and sign messages, with one address.

[fornit]

Then you don't have to do anything with the service other than send them money and sign messages, with one address.

i tihnk this is the problem. you always have to be careful that your money doesnt mix and addresses become linked to each other later. so either you need a separate wallet for each anonymous, reusable address or you need to be able to mark addresses in your client like "never send bitcoins from this address except when explicitly told to do so".

[Haplo]

Why can't you use the mixing service to fund the same address that will be funding the account? 

-- Service provides address, A, to which you want to deposit 20 BTC
-- Create new address, B
-- Send 20 BTC from your regular wallet to the mixer, to be sent to B
-- Send 20 BTC from B to A (through Tor)
-- B is now your permanent identity with that service:  use signed messages to communicate actions.

It's an extra hop, but it maintains the anonymity, because B is used exactly once and never linked to any other address.  And the service doesn't know anything beyond that address B sent 20 BTC and is now empty.  Then you don't have to do anything with the service other than send them money and sign messages, with one address.

Right, I figured that much out. However, I don't know that anyone has created a mixer thus far, so it's pretty moot. It would be one of the main design considerations for a mixer, though.

[etotheipi]

Then you don't have to do anything with the service other than send them money and sign messages, with one address.

i tihnk this is the problem. you always have to be careful that your money doesnt mix and addresses become linked to each other later. so either you need a separate wallet for each anonymous, reusable address or you need to be able to mark addresses in your client like "never send bitcoins from this address except when explicitly told to do so".

Certain built-in safeguards could help.  But what I described above would work fine, too, since you are filling and emptying the address in one round.  The address will never have coins again, and most clients will never reuse any address for receiving or change outputs. 

If you want to refill your account, then get a new address from the service and and send more coins to it, from any other address (or mixer).  What I described above only needs to be done once, and then you can carry on as normal, using only the original address for signing messages declaring your intentions.