Bitcoin transfer with Reference Field like in wire transfer forms

[Michael_S]

Hi,

I have an idea about how a reference field could be added to Bitcoin transfers very neatly and comfortably from the end-user perspective.
Today the usage of reference fields in bank wire transfers is quite useful to link small messages to a money transfer.
I am missing this with Bitcoin.

My Idea now is to do something on top, WITHOUT changing the Bitcoin protocol, that serves exactly this purpose! It would work like this:

Idea:

• Every Bitcoin transfer has a source A and destination B address, a time stamp, and maybe some further unique identifier (I do not know the BTC protocol in detail, other people here in the forum know better and they will understand what I mean)
• Now, after having filled my target address B and amount of BTC in the "send" field of my client software, I am able to compose a message (=free text, like an SMS) and the client will encrypt this message with the public key of B (i.e. with the destination address) in the way that normally emails are encrypted with PGP public key mechanisms.
• After pressing "send", the bitcoin client SW is uploading this encrypted message to a central "Bitcoin-Transfer-SMS" Server (in the sequel called "SMS-server" for brevity).
• Of course, the functions of the two bullets above should be incorporated in the Bitcoin client SW, eventually, for the user's convenience
• And of course, the bitcoin client SW can be configured with more than just one such "Bitcoin-Transfer-SMS"-Server, because we do not want a monopoly of course. Maybe there will be 3 or 4 or 5 such big service providers eventually, and many more (10? 20? 30?) in the beginning
• They all use the same protocol, such that the Bitcoin client SW just needs to be configured with the URL of the server (somebody should write an RFC or something for this protocol - or open source SW stack for this protocol...)
• When I compose this message and make my upload of my public-key-encrypted SMS to this server, I do not even need a login to that server, no password, no registration! Instead, I will transfer a tiny fee to that server's BTC address, and for this the server will do the service for me, i.e. to store the message for some time (e.g. 2 years) in its publically retrievable database.
  How does the server know that the fee is dedicated to this transfer from A to B? Simple! in the background, the client SW just composes another message (SMS) in the same format that is associated to my transfer of the fee to the service provider's BTC address. The content of that message is simply the unique ID of the transaction from A to B, so the SMS-service provider knows where this belongs to.
• The client SW of the recipient B will receive the Bitcoins, and will query the SMS-server(s) to check if a SMS is associated with this transfer. If yes, this client SW can read the message because it possesses the suitable private key for "B" (otherwise it could not receive the money in the first place), and it can display the message neatly in the client's GUI, so all this runs transparently in the background for the end-user.
• Additional idea: To lower the burden (load) of the SMS-servers that they would experience if every client checked every server for every BTC transfer that it receives, there could be an "SMS-server flag" incorporated in the amount of BTCs that are sent, in the least significant bit. Idea: The transfer from A to B is 1.00 BTC, plus e.g. 0.005 BTC for the miners, PLUS 0.00000something BTC additional fee (that would also go to the miners), where "something" in the simplest embodiment of this idea is simple the LSB set to ==1. This would tell the receiving client that this BTC transfer has an associated SMS at one of the SMS servers, and the client would query them. This would significantly reduce the load to the SMS servers, because probably still the majority of BTC transfers will not have any "reference field" (SMS) populated.
  If this LSB is ==0, then the receiving client knows that an associated SMS-message does not exist for this transfer, and it will not query any of the SMS-servers.
  [In a more complex embodyment, we could use e.g. the 5 LSBs to also specify WHICH SMS server was used (or group of SMS servers if number of SMS servers globally active is >32)....just an idea]
  
• ---
• From the end-user perspective, the client's GUI has the following fields:
  * Amount of BTC to send (like today already)
  * Destination address (like today already)
  * Optional fee to the miners (like today already[?])
  * New: Text field for the reference field (SMS), use of this field is optional for the user
  * New: An additional info-field that indicates the extra fee that goes to the SMS server - could also be dependent on the length of the text (like SMS) - depends on the policy of the chosen SMS-server
  * New: A pull-down list to choose the SMS-server (unless this is configured in the "settings" part of the bitcoin client)
  * ---
  * At the receiving side, the end-user will see the incoming transfer, and associated with it another new field with text, that says either "<empty>" (greyed out), or it say "retrieving reference text..." (if the BTC payment amount (LSBs) indicated that an associated msg exists), or it displays the reference text (if the client succeeded in retrieving the SMS text), all this automatically in the background from user perspective
  

I do not think and do not expect that such services will develop soon and that such feature goes into the official BTC client soon - first more important issues especially around security (wallet.dat encryption/export/sync with cloud/FTP, or split of wallet and client etc.) and maybe also around general usability are on the agenda I think. But I wanted to share with you that such feature could eventually be incorporated one day.
Michael

[Atom]

Given the non-existant minimum size, couldn't this also be used as a way to send secure, encrypted messages without ever hitting an email/phone server?

That right there is a damn valuable feature.  .001btc transactions as the new untracable text message

[Gavin Andresen]

Now, after having filled my target address B and amount of BTC in the "send" field of my client software, I am able to compose a message (=free text, like an SMS) and the client will encrypt this message with the public key of B (i.e. with the destination address) in the way that normally emails are encrypted with PGP public key mechanisms.

Bitcoin addresses are not public keys-- they are hashes of public keys (RIPE-MD-160 hash of the SHA256 hash of the public key, with a version number and checksum, to be annoyingly specific).

I agree that associating a message with a bitcoin transaction would be spiffy.

[Michael_S]

Now, after having filled my target address B and amount of BTC in the "send" field of my client software, I am able to compose a message (=free text, like an SMS) and the client will encrypt this message with the public key of B (i.e. with the destination address) in the way that normally emails are encrypted with PGP public key mechanisms.

Bitcoin addresses are not public keys-- they are hashes of public keys (RIPE-MD-160 hash of the SHA256 hash of the public key, with a version number and checksum, to be annoyingly specific).

I agree that associating a message with a bitcoin transaction would be spiffy.

Oh, well I'm not an expert, just know some basics of priv/pub encr like PGP (GPG) at the level of Phil Zimmermann's Intro to Crypto.

So does this mean that my idea cannot work because only the hashes (or hashes' hashes) of the public keys (=Bitcoin addresses) and not the public keys themselves are actually publicly known in the Bitcoin world??
   If so, I would be a little surprised because I always thought that whenever the bitcoin nodes ("miners") want to verify the validity of a BTC transaction's signature, they need to know the corresponding public key (and not only its hash's hash) to perform this check. But then the public key (and not only its hash's hash) is available to the clients, too, and the "SMS-service" could work as described above, couldn't it?
   If really only the hashes' hashes are publicly known in today's Bitcoin universe, then the public key could be uploaded by the transmitting client to the SMS server to a public data base (=lookup table: "public key A's hash's hash" --> "public key A itself") and the mechanism could then work as described in my original post, couldn't it?

[michaelmclees]

Now, after having filled my target address B and amount of BTC in the "send" field of my client software, I am able to compose a message (=free text, like an SMS) and the client will encrypt this message with the public key of B (i.e. with the destination address) in the way that normally emails are encrypted with PGP public key mechanisms.

Bitcoin addresses are not public keys-- they are hashes of public keys (RIPE-MD-160 hash of the SHA256 hash of the public key, with a version number and checksum, to be annoyingly specific).

I agree that associating a message with a bitcoin transaction would be spiffy.

Raising this thread from the dead, because I think it would be a great feature.  Is this being worked on?  Is it feasible?  My thinking is that some people might want to make messaging a primary feature.

If someone wants to send only an encrypted message to a Bitcoin address, perhaps they pay per character or something, which would go towards fees for miners.  Sending a 140 character tweet for example, to a another Bitcoin client might involve sending a minimum transaction, plus the regular fee (if any), plus the message fee (.001 BTC/character) for example.