.

[zinodaur]

.

[1715089347]

1715089347

[1715089347]

1715089347

[1715089347]

1715089347

[1715089347]

1715089347

[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?

[mmeijeri]

You can already encode messages into the blockchain if you want, though the qt client doesn't offer any GUI functionality for this and miners may reject nonstandard transactions.

[cho]

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.

[mmeijeri]

You may also want to take a look at Bitmessage, which is a sort of p2p encrypted e-mail system using proof of work to avoid spamming the network.

[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

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)?

You are right: the idea/challenge is getting Bitmessage client to say "Ok, with this Bitcoin private key [key A], let me generate the Bitmessage identities such that the user can decrypt bit-messages sent to [bitcoin address A] ("the Bitcoin address associated with the corresponding ECDSA public key of this Bitcoin private key") ."

It should be possible, but its definitely a little stranger than the way it is designed now (would have to be a whole to add-on feature). The developer is brainstorming the idea, I think.

[mmeijeri]

Would there be anything wrong with embedding just a hash of a message to the blockchain, for timestamping purposes?

[arsenische]

Come on, text messages are not that big. If the fee is paid and miners decide to put it in block, then what's the problem?

[mmeijeri]

It's not just the miners who bear the costs, it's everyone who stores the whole blockchain. It might even include people who don't store the whole chain if the messages are difficult to prune by those who don't care about them.

[papa_snurf]

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.

Another 'feel free to fork your own shit' reply... it's getting tiresome.

That said we don't want to bloat the blockchain do we?

[arsenische]

I am not sure short paid messages would really bloat the blockchain. Just few additional hundreds bytes per transaction with increased fees. Though it is correct: miners are not the only ones who carry costs. Probably full nodes could prune old messages or messages that are not addressed to them (just to save some disk space).

Update: though probably you are right, it would cause problems (not only blockchain size, but also copyright infringements, propaganda  of racism and other extreme cases of freedom of speech)... Probably better to have messages separate, maybe to integrate with IRC (AFAIK bitcoind had some code to deal with IRC already).

[FlappySocks]

How about something along the line of the new BitTorrent Sync?
http://labs.bittorrent.com/experiments/sync.html

It would be like having a dropbox folder attached to a bitcoin transaction. You could attach anything you wanted, from a simple message to pictures, video, software or any digital content.

[mmeijeri]

Update: though probably you are right, it would cause problems (not only blockchain size, but also copyright infringements, propaganda  of racism and other extreme cases of freedom of speech)... Probably better to have messages separate, maybe to integrate with IRC (AFAIK bitcoind had some code to deal with IRC already).

Perhaps that is a good idea for other reasons as well, but content-related problems would be solved by only embedding a hash, not the whole message.

[roalwe]

I am not sure short paid messages would really bloat the blockchain. Just few additional hundreds bytes per transaction with increased fees. Though it is correct: miners are not the only ones who carry costs. Probably full nodes could prune old messages or messages that are not addressed to them (just to save some disk space).

Update: though probably you are right, it would cause problems (not only blockchain size, but also copyright infringements, propaganda  of racism and other extreme cases of freedom of speech)... Probably better to have messages separate, maybe to integrate with IRC (AFAIK bitcoind had some code to deal with IRC already).

The thing with "pruning" is that, as far as I understand, it deals only with storage, not with bandwidth.

Pruning doesn't really "dislodge" old spent TX from a block (that would screw over the hashes )
It just allows you to discard obviously "spent" stuff after you have recieved it (assuming you follow the "trust no one" doctrine of Satoshi client) - but if the blockchain has bloated to 2 TB due to everyone and their dog putting a message in it, you would still have to download it (somehow).

I believe that Bitcoin should follow its initial design goals, and should not try being everyone's everything (chat client, name resolver, distributed evernote, torrent seeder... )

Just say no to feature bloat.

[FlappySocks]

Attaching messages should defiantly not be part of the block chain IMO, and there is no reason to.  So long as you can tie a message to a transaction, it can be transmitted independently as meta data.

Messages need not be kept in the system indefinitely either.  Once the recipient has received the message, it's their responsibility to archive it (or not). Just like traditional e-mail.

Messages could be limited in size. If you want to attach more, then include URLs to additional content.

[roalwe]

That sounds like a whole lot of fuss for a rather meager goal.

Don't get me wrong, messaging is sweet and all that, but bitcoin devs have finite resources, and I'd very much rather prefer they spend their resources on bitcoin's core functionality.

I am not experiencing a lack of IM software with varying degree of decentralization and anonymity.

[mmeijeri]

I believe that Bitcoin should follow its initial design goals, and should not try being everyone's everything (chat client, name resolver, distributed evernote, torrent seeder... )

Absolutely, but limited encrypted messaging attached to a transaction looks like a core feature of a payment system. Traditional payment systems also have this feature.

In addition, it would be useful to have an application that adds intrinsic value to Bitcoin, as discussed on this page on the bitcoin.it site. The specific application could be something like Bitmessage, but with its PoW scheme replaced by Bitcoin postage.

It would also be nice if the protocol could be layered somehow, with a base layer dealing with generalised notarisation services, and several specialised layers on top of that. Below the notarisation service you could have a generalised message sharing layer and below that a generalised P2P layer that deals with peer discovery and perhaps anonymity. It would also be good to share these layers with other P2P applications like Bittorrent, Tor etc. Sharing the more basic layers with other P2P protocols gives you critical mass, robustness, economies of scale and less duplication of effort.

[runeks]

I believe that Bitcoin should follow its initial design goals, and should not try being everyone's everything (chat client, name resolver, distributed evernote, torrent seeder... )

Absolutely, but limited encrypted messaging attached to a transaction looks like a core feature of a payment system. Traditional payment systems also have this feature.

I disagree. A messaging system should not be in the core part of a decentralized currency.

We have so many ways of sending simple text messages to each other. Why on earth would we want to put this sort of trivial data in the block chain, to be stored for ever and ever?

Every single bitcoin transaction is necessary for the system to work; we need them to figure out if an output has been spent.

Messages like "A no. 5 with extra cheese and mushrooms" is the exact opposite: absolutely irrelevant to the currency itself, and utterly unimportant as soon as the good that the payment was for has been delivered and consumed. Storing this message for eternity in the block chain would be a waste of the scarcest resource in the Bitcoin system: storage space.

[mmeijeri]

I'm not saying the message should be in the deepest Bitcoin-specific layer or stored in the block chain. Nevertheless it would be useful to have standard functionality in the full protocol and in the reference client for specifying things like "A no. 5 with extra cheese and mushrooms".

[Kluge]

I believe that Bitcoin should follow its initial design goals, and should not try being everyone's everything (chat client, name resolver, distributed evernote, torrent seeder... )

Absolutely, but limited encrypted messaging attached to a transaction looks like a core feature of a payment system. Traditional payment systems also have this feature.

I disagree. A messaging system should not be in the core part of a decentralized currency.

We have so many ways of sending simple text messages to each other. Why on earth would we want to put this sort of trivial data in the block chain, to be stored for ever and ever?

Every single bitcoin transaction is necessary for the system to work; we need them to figure out if an output has been spent.

Messages like "A no. 5 with extra cheese and mushrooms" is the exact opposite: absolutely irrelevant to the currency itself, and utterly unimportant as soon as the good that the payment was for has been delivered and consumed. Storing this message for eternity in the block chain would be a waste of the scarcest resource in the Bitcoin system: storage space.

It helps prove intended use of the money (similar to check memo), which might be helpful in law. If the intent is disagreed with, money can be refunded with the memo stating so.

[markm]

I believe that Bitcoin should follow its initial design goals, and should not try being everyone's everything (chat client, name resolver, distributed evernote, torrent seeder... )

Absolutely, but limited encrypted messaging attached to a transaction looks like a core feature of a payment system. Traditional payment systems also have this feature.

And there you have it.

It is NOT a core feature of a currency, in fact although some jurisdictions might not currently prosecute people for writing messages on e.g. dollar bills, I believe there was a time and/or are or have been jurisdictions where "defacing a coin of the realm" was not only offensive but "an offense".

Bitcoin is a currency. Stand by for a payment system, "coming soon". (4 to 6 weeks or so? )

-MarkM-

[mmeijeri]

It is NOT a core feature of a currency, in fact although some jurisdictions might not currently prosecute people for writing messages on e.g. dollar bills, I believe there was a time and/or are or have been jurisdictions where "defacing a coin of the realm" was not only offensive but "an offense".

Is Bitcoin supposed to be only a currency, not a payment system?

Bitcoin is a currency. Stand by for a payment system, "coming soon". (4 to 6 weeks or so? )

You mean Ripple? I'm very enthusiastic about that, but I'd also like to see basic messaging functionality in Bitcoin clients, including the reference client.

[markm]

You didn't read? I coulda sworn someone or more than one someones specifically mentioned, probably more than once, the payment system stuff the devs are actively developing?

-MarkM-

[mmeijeri]

You didn't read? I coulda sworn someone or more than one someones specifically mentioned, probably more than once, the payment system stuff the devs are actively developing?

I read the thread and didn't see any such announcements. I fully agree we shouldn't bloat the block chain, and that there may need to be separate layers, but what's the problem with a 60 byte max memo attached to a transaction, just as with bank transactions? Or even just a hash?