Messages with or about transactions #13

It'd be cool if there was some mechanism for secure communication between sender/receiver.

Ideally, the mechanism would be secure from eavesdroppers and authenticated by the bitcoin addresses involved (so would be as anonymous as those addresses).

Also ideally either store-and-forward (email-like) AND/OR real-time (instant-message-like) communication should be possible.

Storing the messages in the block chain as part of transactions (as proposed by several people) is probably NOT the right approach. And building the actual message communication into core bitcoin may not be the right approach.

Use cases to design for:

• Store wants to send anonymous customer information on status of an order they paid for a while ago. (example: "free upgrade for the software you bought last week is available" or "warning: the file you downloaded yesterday has been reported to contain malware") -- what about possiblity of spam?
• Customer wants to send authenticated message about a payment they sent (example: "I messed up the shipping address, please send to '123 main street' instead of '213 main street'" or "the file I just got from you contains a virus")

Bitcoin knows how to sign transactions with the public key corresponding to a bitcoin address; the key feature needed is, Gavin thinks, authentication: are you really communicating with the sender/receiver of bitcoin address? Perhaps bitcoin could support a function "please sign this arbitrary stuff with bitcoin address for which you have the private key and return the digital signature"; that might be sufficient to integrate with existing secure messaging infrastructure (like PGP email).

There's definitely something to this.

I think the spam potential of your first use case is too nasty to contemplate. I'd be satisfied with commerce systems including a business rule which says "if you want further notifications, attach an email address to your order". The spam problem is already addressed broadly in the email domain, and email addresses can be rather anonymous.

Signing an email with the bitcoin key is a neat idea, but there's a lack of symmetry in the typical commerce application. Customer learns a bitcoin address for vendor, so vendor can later sign messages back to customer using that address's private key. Not so in the reverse, unless the customer provides an address of their own as part of the exchange.

What I would like to see is the ability to attach a small, optional data field to a transaction. For example, here in Slovakia, the banking system provides for the attachment of several fields to an electronic payment: constant symbol (4), variable symbol (10), specific symbol (16?), note (32?). The constant symbol is used for tax accounting purposes, and the rest are used to correlate payments with accounts, similar to "please be sure to include your account/invoice number on your check".

I'm guessing this is already provided for in the protocol, though I'm not familiar with that part of the implementation. Also, it's arguable that it's not necessary if a merchant generates a new bitcoin address for each payment. Not a big priority, really.

Is the bitcoin receiver address equivalent to a public key? If so, it could be used to encrypt a message that only the recipient could read. Together with the ability to sign the message with the sender's bitcoing address this could be the basis for a very simple (but secure) out-of-band messaging system:

If you happen to know a way to contact the recipient, you just send him a signed message (you yourself can even stay anonymous, but the message can be reliable attributed to your sender bitcoin address).

If you do not know a way (or do not trust the transportation channel), an encrypted message could be posted on a public board where the recipient could eventually pick it up. Notifications/polling could be integrated into the GUI application.

Again, everything out-of-band (not messing with the existing payment infrastructure), and it depends (at least for the encryption part) on a bitcoin receiver address functioning as an encryption key (does it?).

The receiver address is a hash of the public key; you don't see the full public key until the transaction is spent.

"The receiver address is a hash of the public key; you don't see the full public key until the transaction is spent."

In this case, we can still sign messages regarding any payments we made, but we can only encrypt them, after the recipient has made any payment himself (at any time, potentially even before we made our payment, in case the "account number" has been used before)

I think that is already enough to get some useful functionality going. This does not have even have to happen within the bitcoin. Are there tools to export private keys from your wallet and extract public keys from the block chain into standard formats for systems like openssl or PGP to use?

"The receiver address is a hash of the public key; you don't see the full public key until the transaction is spent."

So one thing that you could always do is to send an encrypted thank you message to someone who has sent you bitcoins (send = broadcast in case you don't know who that is)

Part of this is implemented through message signing.

Closing; I think the message signing/verifying gives enough low-level support for interesting things to be built.