.

[zinodaur]

.

[1713896481]

1713896481

[Zeilap]

Attaching messages to transactions that get stored in the blockchain is highly wasteful and won't be implemented.
However, what will be possible in the next version is something like you want: Instead of making a payment by taking the payment address, creating a transaction and broadcasting it yourself, you'll instead be able to create the transaction and wrap it up with some other information like a message to the receiver, and then you send this whole thing to the receiver directly (like by submitting it to their website). The receiver then has the choice whether to accept the payment in which case he broadcasts it himself, or declines the payment, either way sending you a reply to tell you whether it's accepted or declined and additionally a message.

[Kluge]

Given devs are scrambling to solve the problem of "blockchain bloat," making it easier to insert/read messages is probably pretty low-priority.

[grue]

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.

[Kluge]

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.

[Gavin Andresen]

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...

[wumpus]

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

[wumpus]

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

[Pieter Wuille]

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

I agree completely.

[AsymmetricInformation]

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

[keatonatron]

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?

[wumpus]

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.

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.

[Bitsaurus]

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.

[keatonatron]

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)

[Rassah]

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.

[keatonatron]

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:

Custom Send - Advanced Send form with coin control. With ability to embed messages in the blockchain.

[wumpus]

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.

[porcupine87]

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%.

[wumpus]

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.

[porcupine87]

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.

Wouldn't the message just be broadcasted by the sender and then the miners pick it up and store on their server? The message would be seperated from the normal transaction.

Also it would be quite unreliable, as mining nodes can go offline at any time.

Then they don't get the money. I mean the recipient could just send an e-mail to message collector (it does not have to be a miner) and then the recipient get the message. Of course, fully automatic.

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.

Then take the hashed public key as public key or a different public key. I thought the public key just get hashed for convenience?


You are all geniuses and can't figure it out how to send an subject like we know it from normal bank account transactions?