Suggestion: Allow short messages to be sent together with bitcoins ?
Bitcoin is great, but it misses one thing that usual bank transfers have: payment title.
Perhaps it should be possible to include short (<=512 bytes) message for each transaction. The message could be encrypted with public/private keys so only the receiver can see its contents.
What do You think ?
PS. I might be wrong, but the messages could also be used to increase randomness of hashing process by the way, couldn’t they ? If not, never mind.
I found something interesting.
http://stackoverflow.com/questions/1138345/best-compression-algorithm-for-short-text-strings
There is a small OS project on github, which does good compression of short text strings.
http://github.com/antirez/smaz
So we could further get the 384 bytes down to <200 or <175 bytes.
I also wonder if the message has to be taken into account for the hash computation. Not doing so would allow to delete it later.
I very much don’t like this idea of a message. Since it is not necessary to the protocol, I’m not sure if it would be easy to find a place where it really fits. I’m not a programmer though. I’d be curious to have Satoshi’s thought on this.
Edit. I have a funny idea. Imagine that numeric precision is increased way beyond 8 decimals, say 128 decimals for instance.
What about using those decimals to code your message ? Somehow you would have a “natural fee” for this service, and we won’t have to modify anything from the protocol.
Edit #2. Gosh I LOVE this idea 😊
Edit #3. We don’t need 128 decimals. Correct me if I’m wrong, but with 32 decimals you can code a 17 characters-longed uncompressed message in a 64 characters set. (32*log(10)/log(64) = 7.717)
I very much don’t like this idea of a message. Since it is not necessary to the protocol, I’m not sure if it would be easy to find a place where it really fits. I’m not a programmer though. I’d be curious to have Satoshi’s thought on this.
Yeah, I’m curious of that too.
ECDSA can’t encrypt messages, only sign signatures.
It would be unwise to have permanently recorded plaintext messages for everyone to see. It would be an accident waiting to happen.
If there’s going to be a message system, it should be a separate system parallel to the bitcoin network. Messages should not be recorded in the block chain. The messages could be signed with the bitcoin address keypairs to prove who they’re from.
ECDSA can’t encrypt messages, only sign signatures.
It would be unwise to have permanently recorded plaintext messages for everyone to see. It would be an accident waiting to happen.
If there’s going to be a message system, it should be a separate system parallel to the bitcoin network. Messages should not be recorded in the block chain. The messages could be signed with the bitcoin address keypairs to prove who they’re from.
I think I didn’t exactly understand how the system works. So if the messages would be sent together with bitcoin, they will also be permamently stored in the block chain for ages.
It seems you’re right, satoshi.
Bitcoin is great, but it misses one thing that usual bank transfers have: payment title.
Perhaps it should be possible to include short ( The message could be encrypted with public/private keys so only the receiver can see its contents.
What do You think ?
PS. I might be wrong, but the messages could also be used to increase randomness of hashing process by the way, couldn’t they ? If not, never mind.
This could be done externally via encrypted jabber, email or any number of other methods. All that would need to be done to permit a message to be sent that could be associated to a particular transaction is create a summation number of the transaction to be pasted into the short message, followed by the short message either cleartext or by some agreed upon encryption method such as public key encryption and then signed by the same bitcoin key used to sign the transaction. This message could be sent to the receiver by any method, never to be included inside a block, but can be verified as well as definatively associated with a particular transaction regardless of how the transaction comes to the receiver.
Quote from: grondilu on October 23, 2010, 3:28:34 PM UTCa paiement label is not necessary.
Sure it is “not necessary” but still would be useful for people.
Perhaps some people would like to keep one BTC address for some reasons. Also bigger financial institutions won’t really like the idea of different account number for each transation.
Call it a transaction number and they’ll insist that it be different each time.
It would be unwise to have permanently recorded plaintext messages for everyone to see. It would be an accident waiting to happen.
What bad effect would you anticipate?
This is already sort-of possible with the current system due to the broadband subchannel in ECDSA.
I was looking for ways of distributing arbitrary information in the block chain to support the implementation of a full client which did not have to bother remembering the entire block chain.
See http://bitcointalk.org/index.php?topic=505.0 - a thread about “Balance Sheets”
A naive way of encoding the data would be based on sending money to a variety of addresses, the data to be decoded by examining let’s say the first couple of of bytes of the receiving addresses but this is rather wasteful of bandwidth with many transactions required to transmit relatively little data.
An interesting property of DSA is that if you’re trying to sign a 32 byte message then each signature is 64 bytes long. This means that the signature includes 32 bytes of information just created out of thin air. If you look up the algorithm http://en.wikipedia.org/wiki/Digital_Signature_Algorithm , this information comes from the random parameter k. A signature consists of a pair of numbers g^k and another expression involving both k and g^k. If you could choose k such that g^k contained your data then you could include your plaintext data in the block chain in great big chunks. (Un)Fortunately, doing this has to be hard otherwise ECDSA is insecure.
However, if you effectively release the private key then everyone can, through some simple algebra recover the k values used in all your signatures signed with that key. I was not the first to realize this. See http://en.wikipedia.org/wiki/Subliminal_channels.
If you’ve spent all the money associated with that key then you don’t care about it anymore. (Of course if someone sends more money to that key then everyone will race to spend it!) So you can encode a load of data in some normal transactions for days or months or whatever and then effectively release your private key (for which there is an elegant method) and then all the data is plain to see.
Of course my “balance sheet” scheme does not suffer from this problem (if problem it is) so badly 😉
ByteCoin