(context post by NewLibertyStandard)
I certainly wouldn’t mind a larger Bitcoin application if it meant we could send an encrypted message along with each transaction. Right now I require an email message from customers who send me bitcoins. This is not ideal because if another person knew about a transaction that was occurring, they could take credit for the transaction by sending a message before the person who sent the bitcoins. About how many MB do you think it would add? Of course these messages will add to the size of the confirmation blocks being stored, so there should probably be a maximum size. Perhaps 256 characters would be a good maximum since the maximum size of an email address is 254 characters.
It would also be nice if transactions included a return address so that if a product or service being purchased can’t be delivered the seller could more easily and reliably refund the bitcoins.
A balance between extended transaction data while NOT becoming an instant messenger client would be nice. Tongue
Quote from: NewLibertyStandard on January 28, 2010, 09:58:17 AM
Right now I require an email message from customers who send me bitcoins. This is not ideal because if another person knew about a transaction that was occurring, they could take credit for the transaction by sending a message before the person who sent the bitcoins.
Why don’t you make them send the email before the transaction? Then you could reply to that email with a new and unique bitcoin address. You don’t even need to use email, it would be equally secure, although not that anonymous, to announce the customers email together with the bitcoin address on the frontpage of your site.
The method you are using now is equal to someone sending you cash in an envelope anonymously, including a note with the time he posted it, after which you send goods back to the first person calling you stating the time and amount in the envelope. (Including the mailman and anyone who has access to you mailbox). Tongue
Sending the email before the transaction is equal to someone calling you, getting a unique box address which to send the money to. When the money arrives to that post box, you send the goods to the customer.
The recommended ways to do a payment for an order:
- The merchant has a static IP, the customer sends to it with a comment.
- 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.