I am working on a thing that allows you to send messages to Bitcoin Addresses. Its outside of the block chain and can be used for instant messager and email type applications.
https://github.com/haltingstate/telehash/blob/master/README.md
Topic: Messaging layer built into the protocol (Read 863 times)
Relay OP_RETURN TxOut will be a standard transaction in Bitcoin 0.9. So then you will be able to send messages and data without clogging up the blockchain.
https://bitcoinfoundation.org/blog/?p=290
https://bitcoinfoundation.org/blog/?p=290
There are of course other issues to consider with regards to messaging, such as how to prevent spam (tx fees seem like the most obvious answer, but will people be willing to pay even trivial fees just to sign a transaction?).
This is the rub. You are either forcing lots of people who don't care about the data to receive it, or you are forcing lots of people who don't care about the data to receive it and those who do pay a tx fee. These are things better tackled outside of the primary network, imo.
Just a quick idea, any thoughts? I think some sort of message layer built into the protocol would be great (though how exactly it should be implemented needs some consideration). With the ability to send messages between users, people could design their own custom protocol extensions and clients to handle them. Three examples:
******************
1) Multi-pass contracts
Consider some sort of contract that requires a raw transaction to be passed around multiple users for signing before being broadcast. Traditionally this passing round would either have to be done manually, through a central service like Blockchain.info, or else through a client application that relies on a messaging protocol like e-mail/SMS/bitmessage or communicates with a central server or connects to a second P2P network (distinct from Bitcoin) to transmit and receive the messages.
With messaging, users could send special messages to each other's addresses which certain clients could parse and respond by opening a dialogue asking the user to sign, delay signing or reject the transaction (or for instance in the case of a 2-of-3 signatures transaction if the user who is to receive the funds by the transaction receives a message their client could automatically sign it because there is no risk). This could automate complex contract operations.
Example message:
#ADDRESS
#SIGN_&_TRANSMIT
[#RAW_TRANSACTION]
2) Trustless mixing
Rather than relying on a centralised server for mixer, or even a centralised server for collating outputs and signatures for trustless mixing, or having to connect to a second P2P network, a client (or a client add-on) could be designed that handles messages of a certain format/content.
A user would trasmit a message to the whole network of a certain form, containing only the output(s) of their intended mixed transaction, then other users wishing to participate in the mixing would add their outputs to the message and retransmit it, then when it had enough outputs (or a certain time limit had elapsed or whatever) it would (somehow) request all the participants to add their inputs, then would go round again asking for signatures. The exact mechanics of this are vague, I haven't really thought about this one in detail, but this is not the idea I'm proposing, just an example.
3) News and market data
Exchangers could transmit signed and time-stamped market price information every so often, which clients could pick up and display to users. Nodes with two messages signed by the same exchanger with the same id but with different time-stamps would simply delete the older one in favour of the newer one, meaning such updates would not bloat the "message chain" or whatever.
Similarly, Bitcoin/cryptocurrency news websites could broadcast news updates which expire after a certain time limit. Forums could even broadcast new posts which users could configure their client to look out for (e.g. threads started by certain users, new replies to certain threads). There are so many possibilities, this would be a really great feature.
**********
The point is that rather than clients having to rely on external servers/p2p networks or else having to lobby the dev team for a major change to the protocol, a messaging layer would enable new functionalities to be developed independently. Rather than a centralised decision about what protocol extensions should go in, individual clients can offer different services (which obviously won't be compatible with all users necessarily to begin with), and the popular ones will be implemented by all/most clients/wallets. The really popular ones can become "canon" and considered part of the core Bitcoin protocol itself.
The use of Bitcoin purely for decentralised messaging is pointless and would be underused, as there are plenty of dedicated services out there already providing this. But a messaging layer within the Bitcoin protocol would be a major advancement.
I don't think messaging should be implemented directly into the block-chain; not only would this bloat it, but it is pointless: there is no need to have a full public ledger of all (probably encrypted) messages that have ever been sent. Only the ones that haven't been dealt with need to be available. There are of course other issues to consider with regards to messaging, such as how to prevent spam (tx fees seem like the most obvious answer, but will people be willing to pay even trivial fees just to sign a transaction?). Apologies I haven't presented a full working concept, but I definitely think it's something to be looked into.
******************
1) Multi-pass contracts
Consider some sort of contract that requires a raw transaction to be passed around multiple users for signing before being broadcast. Traditionally this passing round would either have to be done manually, through a central service like Blockchain.info, or else through a client application that relies on a messaging protocol like e-mail/SMS/bitmessage or communicates with a central server or connects to a second P2P network (distinct from Bitcoin) to transmit and receive the messages.
With messaging, users could send special messages to each other's addresses which certain clients could parse and respond by opening a dialogue asking the user to sign, delay signing or reject the transaction (or for instance in the case of a 2-of-3 signatures transaction if the user who is to receive the funds by the transaction receives a message their client could automatically sign it because there is no risk). This could automate complex contract operations.
Example message:
Code:
[#RAW_TRANSACTION]
2) Trustless mixing
Rather than relying on a centralised server for mixer, or even a centralised server for collating outputs and signatures for trustless mixing, or having to connect to a second P2P network, a client (or a client add-on) could be designed that handles messages of a certain format/content.
A user would trasmit a message to the whole network of a certain form, containing only the output(s) of their intended mixed transaction, then other users wishing to participate in the mixing would add their outputs to the message and retransmit it, then when it had enough outputs (or a certain time limit had elapsed or whatever) it would (somehow) request all the participants to add their inputs, then would go round again asking for signatures. The exact mechanics of this are vague, I haven't really thought about this one in detail, but this is not the idea I'm proposing, just an example.
3) News and market data
Exchangers could transmit signed and time-stamped market price information every so often, which clients could pick up and display to users. Nodes with two messages signed by the same exchanger with the same id but with different time-stamps would simply delete the older one in favour of the newer one, meaning such updates would not bloat the "message chain" or whatever.
Similarly, Bitcoin/cryptocurrency news websites could broadcast news updates which expire after a certain time limit. Forums could even broadcast new posts which users could configure their client to look out for (e.g. threads started by certain users, new replies to certain threads). There are so many possibilities, this would be a really great feature.
**********
The point is that rather than clients having to rely on external servers/p2p networks or else having to lobby the dev team for a major change to the protocol, a messaging layer would enable new functionalities to be developed independently. Rather than a centralised decision about what protocol extensions should go in, individual clients can offer different services (which obviously won't be compatible with all users necessarily to begin with), and the popular ones will be implemented by all/most clients/wallets. The really popular ones can become "canon" and considered part of the core Bitcoin protocol itself.
The use of Bitcoin purely for decentralised messaging is pointless and would be underused, as there are plenty of dedicated services out there already providing this. But a messaging layer within the Bitcoin protocol would be a major advancement.
I don't think messaging should be implemented directly into the block-chain; not only would this bloat it, but it is pointless: there is no need to have a full public ledger of all (probably encrypted) messages that have ever been sent. Only the ones that haven't been dealt with need to be available. There are of course other issues to consider with regards to messaging, such as how to prevent spam (tx fees seem like the most obvious answer, but will people be willing to pay even trivial fees just to sign a transaction?). Apologies I haven't presented a full working concept, but I definitely think it's something to be looked into.
Jump to: