Yes, it's a technical limitation. Sending by bitcoin address enters the transaction into the network and the recipient discovers it from the network. You don't connect directly with them and they don't have to be online at the time.
I very much wanted to find some way to include a short message, but the problem is, the whole world would be able to see the message. As much as you may keep reminding people that the message is completely non-private, it would be an accident waiting to happen.
Unfortunately, ECDSA can only sign signatures, it can't encrypt messages, and we need the small size of ECDSA. RSA can encrypt messages, but it's many times bigger than ECDSA.
Re: A newb's test - anyone want to buy a picture for $1?
The recommended ways to do a payment for an order:
1) The merchant has a static IP, the customer sends to it with a comment.
2) The merchant creates a new bitcoin address, gives it to the customer, the customer sends to that address. This will be the standard way for website software to do it.
RSA vs ECDSA: it's not the size of the executable but the size of the data. I thought it would be impractical if the block chain, bitcoin addresses, disk space and bandwidth requirements were all an order of magnitude bigger. Also, even if using RSA for messages, it would still make sense to do all the bitcoin network with ECDSA and use RSA in parallel for only the message part. In that case, everything that's been implemented up to now would be implemented exactly as it has been.
We can figure out the best way to do this much later. It could use a separate (maybe existing) e-mail or IM infrastructure to pass messages, and instead of RSA, maybe just put a hash of the message in the transaction to prove that the transaction is for the order described in the message. The message would have to include a salt so nobody could brute force the hash to reveal a short message.
1) The merchant has a static IP, the customer sends to it with a comment.
2) The merchant creates a new bitcoin address, gives it to the customer, the customer sends to that address. This will be the standard way for website software to do it.
RSA vs ECDSA: it's not the size of the executable but the size of the data. I thought it would be impractical if the block chain, bitcoin addresses, disk space and bandwidth requirements were all an order of magnitude bigger. Also, even if using RSA for messages, it would still make sense to do all the bitcoin network with ECDSA and use RSA in parallel for only the message part. In that case, everything that's been implemented up to now would be implemented exactly as it has been.
We can figure out the best way to do this much later. It could use a separate (maybe existing) e-mail or IM infrastructure to pass messages, and instead of RSA, maybe just put a hash of the message in the transaction to prove that the transaction is for the order described in the message. The message would have to include a salt so nobody could brute force the hash to reveal a short message.