I've been wondering about messages associated to transactions for a while. It's good to see there might be clever ways to do this without storing them in the blockchains.
One use amongs many : send a message with a tip, gift or donation.
Topic: . - page 2. (Read 3232 times)
Why centralized? The miner takes the transactions and stores the messages associated to the outputs on its own server. If the recipient want to read the message, he has to pay the miner a small fee. After a certain time, the miner deletes that message.
Not impossible, but getting miners to store messages and letting them offer an interface to read them would be a huge change to the protocol.Privacy: Isn't it possible to encrypt the message with the public key of the recipient? (after the signature of the sender)
No, this is not possible, as mentioned before. Please read the thread before commenting.You are all geniuses and can't figure it out how to send an subject like we know it from normal bank account transactions?
Why centralized? The miner takes the transactions and stores the messages associated to the outputs on its own server. If the recipient want to read the message, he has to pay the miner a small fee. After a certain time, the miner deletes that message.
Not impossible, but getting miners to store messages and letting them offer an interface to read them would be a huge change to the protocol. Also it would be quite unreliable, as mining nodes can go offline at any time.Privacy: Isn't it possible to encrypt the message with the public key of the recipient? (after the signature of the sender)
No, this is not possible, as mentioned before. Please read the thread before commenting.Maybe add a flag to the transaction if there is a memo. The recipient can go the a website where the memo can be pulled up. Miner fees would subsidize the hosting of the memo, maybe paying 100 satoshi or something for the memo.
That is much better than embedding the messages themselves in the chain. However, we can never support this in the reference client because it a) relies on a centralized website b) provides no privacy, everyone on the world can look up the message.Why centralized? The miner takes the transactions and stores the messages associated to the outputs on its own server. If the recipient want to read the message, he has to pay the miner a small fee. After a certain time, the miner deletes that message.
Privacy: Isn't it possible to encrypt the message with the public key of the recipient? (after the signature of the sender)
In my option there has to be a possibility for the exchance messages. Btw, storing a 50-letter-long message would increase the size of a trancation by 5%.
Maybe add a flag to the transaction if there is a memo. The recipient can go the a website where the memo can be pulled up. Miner fees would subsidize the hosting of the memo, maybe paying 100 satoshi or something for the memo.
That is much better than embedding the messages themselves in the chain. However, we can never support this in the reference client because it a) relies on a centralized website b) provides no privacy, everyone on the world can look up the message.In principle this would already be possible without any changes to the block chain at all; someone could make a website that associates messages to transaction IDs. I suppose that's what blockchain.info does.
I think blockchain.info messages are local only to blockchain.info, and are not stored in the actual blockchain.
If so, that would be closer to what the OP wants, but still make others in this thread happy by not bloating the blockchain
Although it would require a central server... (maybe not so bad, if you accept that messages are public and not necessarily reliable/secure)However, on the features page under "transaction types", blockchain.info lists:
Quote
Custom Send - Advanced Send form with coin control. With ability to embed messages in the blockchain.
The main block chain is not suited to this. "let's spam my messages to the world and burden them forever" is not an acceptable solution. Maybe you should have read the thread before commenting.
I did read the thread. And I never said adding messages to the blockchain is a good thing.
The OP asked why this hasn't been done before, but it has. No one else mentioned that, and I was curious why. (I know it's a bad idea, but regardless blockchain.info is doing it)
I think blockchain.info messages are local only to blockchain.info, and are not stored in the actual blockchain.
The main block chain is not suited to this. "let's spam my messages to the world and burden them forever" is not an acceptable solution. Maybe you should have read the thread before commenting.
I did read the thread. And I never said adding messages to the blockchain is a good thing.
The OP asked why this hasn't been done before, but it has. No one else mentioned that, and I was curious why. (I know it's a bad idea, but regardless blockchain.info is doing it)
You may be interested in an idea that I had, which I actually think is pretty simple:
You use your bitcoin address's private key to generate a Bitmessage identity that can read messages "sent to that bitcoin address" though bitmessage because bitmessage can (probably) reinterpret the bitcoin address as a bitmessage address.
Unfortunately I havent thought through the details at all so there has been zero progress.
https://bitcointalk.org/index.php?topic=128230.120
Cool, I'll take a better look later.You use your bitcoin address's private key to generate a Bitmessage identity that can read messages "sent to that bitcoin address" though bitmessage because bitmessage can (probably) reinterpret the bitcoin address as a bitmessage address.
Unfortunately I havent thought through the details at all so there has been zero progress.
https://bitcointalk.org/index.php?topic=128230.120
I suppose the problem is that whereas you can (trivially) reinterpret your private key as a bitmessage identity, can you also convert an existing bitcoin address to a bitmessage address that matches that private key (without having the actual private key)?
Stupid question: Blockchain.info allows you to embed messages in the blockchain when sending a transaction. How does this differ from the OP's request?
The main block chain is not suited to this. "let's spam my messages to the world and burden them forever" is not an acceptable solution. Maybe you should have read the thread before commenting. The difficult part is not so much where to store the messages; heck, they could be sent through e-mail. The problem is routing, so how to associate message endpoints with a bitcoin address, and how to encrypt data to a bitcoin address so that the rest of the world cannot read it or do statistics on it.
You may be interested in an idea that I had, which I actually think is pretty simple:
You use your bitcoin address's private key to generate a Bitmessage identity that can read messages "sent to that bitcoin address" though bitmessage because bitmessage can (probably) reinterpret the bitcoin address as a bitmessage address.
Unfortunately I havent thought through the details at all so there has been zero progress.
https://bitcointalk.org/index.php?topic=128230.120
You use your bitcoin address's private key to generate a Bitmessage identity that can read messages "sent to that bitcoin address" though bitmessage because bitmessage can (probably) reinterpret the bitcoin address as a bitmessage address.
Unfortunately I havent thought through the details at all so there has been zero progress.
https://bitcointalk.org/index.php?topic=128230.120
These issues make me think that the place for messages is in a payment protocol *above* bitcoin addresses. Which is what is being worked on.
https://gist.github.com/gavinandresen/4120476
https://gist.github.com/gavinandresen/4120476
I agree completely.
I was actually thinking of including it only in the QT software, without any links to the blockchain. Separated.
If there was a straightforward way to do this it would have been done long ago.You are right that there is no need for it to be in the block chain, or even run over the same P2P network.
But what about security? As a bitcoin address is a *hashed* public key, it cannot be used as-is to encrypt a message to the recipient of the coins. I'm not sure how bitmessage solved this, haven't checked it in detail.
I suppose one could do a PGP keyserver kind of trick and advertise an encryption key (and some way of specifying where to send the message, such as a network address) based on the address. This is then signed with the address's key to check authenticity. Then again, adresses are meant to be used only once, in contrary to PGP public keys which identify a person. So this would result in extremely bloated keyservers. The records could expire after a while, of course... And wouldn't really be decentralized, either, when using servers. And everyone that wants to receive messages would have to broadcast their info.
These issues make me think that the place for messages is in a payment protocol *above* bitcoin addresses. Which is what is being worked on.
https://gist.github.com/gavinandresen/4120476
the blockchain is designed to be a ledger, not a place to put your messages. if you want to do that, feel free to create your own "message coin" fork.
Message coin fork: https://bitmessage.org/wiki/Main_Page
I think including a message that is NOT stored in the blockchain but is just broadcast across the network is a good idea. The receiver would only get the message if they were online and saw the transaction broadcast, but I think that would be fine (and perhaps services would spring up to deliver the extra transaction data associated with old transactions).
First, though, I think the transaction memory pool needs to be re-implemented, and the transaction relaying rules need to be changed so that the entire size of the transaction (not just the part that will be stored in the block chain) is considered in the priority/fee calculations.
And fixing the client so it calculates fees properly is higher priority...
First, though, I think the transaction memory pool needs to be re-implemented, and the transaction relaying rules need to be changed so that the entire size of the transaction (not just the part that will be stored in the block chain) is considered in the priority/fee calculations.
And fixing the client so it calculates fees properly is higher priority...
the blockchain is designed to be a ledger, not a place to put your messages. if you want to do that, feel free to create your own "message coin" fork.
There's a pretty big and obvious benefit to include time-stamped "memos" directly with payments. Idunno exactly how fees and messages would work, but assuming it counts toward BTC/kB fee, seems like a pretty reasonable (if poorly-timed) request. 
Jump to: