Messages with or about transactions #13

1. 
   gavinandresen commented at 2:51 pm on December 22, 2010: contributor

   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).

2. 
   mikegogulski commented at 1:44 am on January 7, 2011: none

   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.

3. 
   thiloplanz commented at 11:29 pm on March 24, 2011: none

   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?).

4. 
   gavinandresen commented at 1:13 am on March 25, 2011: contributor

   The receiver address is a hash of the public key; you don’t see the full public key until the transaction is spent.
5. 
   thiloplanz commented at 1:25 am on March 25, 2011: none

   “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?

6. 
   thiloplanz commented at 11:39 am on April 7, 2011: none

   “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)

7. laanwj referenced this in commit 8c4738d5a7 on Sep 18, 2011
8. 
   sipa commented at 10:06 pm on February 27, 2012: member

   Part of this is implemented through message signing.
9. 
   gavinandresen commented at 11:34 pm on February 27, 2012: contributor

   Closing; I think the message signing/verifying gives enough low-level support for interesting things to be built.
10. gavinandresen closed this on Feb 27, 2012

    ---

11. dasher referenced this in commit 7f142b479b on Dec 18, 2012
12. nelisky referenced this in commit 5112a4105e on Nov 8, 2013
13. kac- referenced this in commit 2d34152a13 on Mar 25, 2014
14. rebroad referenced this in commit 97cac8b6c5 on Jul 21, 2014
15. dexX7 referenced this in commit dca2c7aeb2 on Feb 7, 2015
16. rubensayshi referenced this in commit 5ebeca560c on Mar 16, 2015
17. dexX7 referenced this in commit 37607273d2 on Apr 8, 2015
18. dexX7 referenced this in commit e7a9a3c3f3 on May 5, 2015
19. MarcoFalke referenced this in commit 313e7f5c89 on Oct 9, 2015
20. brishtiteveja referenced this in commit c30675c998 on Jan 25, 2016
21. ptschip referenced this in commit 01f3a35757 on Feb 19, 2016
22. laanwj referenced this in commit cf44e4ca77 on Jun 13, 2017
23. AkioNak referenced this in commit 9d1cd983f5 on Jul 25, 2017
24. MarcoFalke referenced this in commit 5839ac3311 on Sep 29, 2017
25. classesjack referenced this in commit 7592eadae4 on Jan 2, 2018
26. HashUnlimited referenced this in commit 4ebfc2a376 on Mar 6, 2018
27. KrzysiekJ referenced this in commit 2b915f62e3 on Mar 28, 2018
28. effectsToCause referenced this in commit 800650ac07 on Jun 22, 2018
29. DigiGreenCoin referenced this in commit e4000aad63 on Oct 29, 2019
30. MarcoFalke referenced this in commit fa0b3da36c on Oct 30, 2019
31. laanwj referenced this in commit b586bbd558 on Nov 6, 2019
32. laanwj referenced this in commit 97b66d34eb on Nov 7, 2019
33. laanwj referenced this in commit e9c85bb139 on Nov 7, 2019
34. laanwj referenced this in commit c92f7af618 on Nov 7, 2019
35. laanwj referenced this in commit 656712fe94 on Dec 9, 2019
36. laanwj referenced this in commit 4abd92d5c4 on Dec 12, 2019
37. Warchant referenced this in commit 7958da26e8 on Dec 31, 2019
38. laanwj referenced this in commit 89c8fe5189 on Jan 2, 2020
39. laanwj referenced this in commit 66480821b3 on Jan 28, 2020
40. MarcoFalke referenced this in commit 5e1728017b on Feb 9, 2020
41. KolbyML referenced this in commit 652f901e24 on Aug 1, 2020
42. KolbyML referenced this in commit b94a6191c8 on Sep 4, 2020
43. laanwj referenced this in commit 924a4ff7eb on Oct 29, 2020
44. KolbyML referenced this in commit 3d9f0283ff on Dec 5, 2020
45. rajarshimaitra referenced this in commit ac08c8dec9 on Mar 23, 2021
46. MarcoFalke referenced this in commit bce09da122 on Apr 28, 2021
47. fanquake referenced this in commit fa00bb2c5c on Apr 29, 2021
48. MarcoFalke referenced this in commit eb9a1fe037 on May 7, 2021
49. MarcoFalke referenced this in commit c857148636 on May 15, 2021
50. rajarshimaitra referenced this in commit 74eaf9a040 on Aug 5, 2021
51. DrahtBot locked this on Sep 8, 2021

Contributors
gavinandresen mikegogulski thiloplanz sipa

Labels
Brainstorming