Topic: attaching messages on transactions and retrieving them from the blockchain (Read 1280 times)
July 14, 2016, 06:01:13 PM
Right, there are altcoins like Sia and StorJ for those.
July 14, 2016, 10:50:02 AM
The problem with anything that is "off the chain" is that you can't guarantee that it has been stored (although other storage blockchains do now exist so the OP might want to investigate those).
As I pointed out it would be extremely expensive to store a whole lot of information in the blockchain as it would need to be cut up into 80 byte chunks (each appearing in a separate tx) which you can't even easily guarantee the order (unless you're putting meta-data in those 80 bytes chunks which reduces the storage even further).
I think we can all agree that Bitcoin wasn't designed for data storage and for the most part the OP_RETURN is only useful for the storage of hashes of data or very small messages.
As I pointed out it would be extremely expensive to store a whole lot of information in the blockchain as it would need to be cut up into 80 byte chunks (each appearing in a separate tx) which you can't even easily guarantee the order (unless you're putting meta-data in those 80 bytes chunks which reduces the storage even further).
I think we can all agree that Bitcoin wasn't designed for data storage and for the most part the OP_RETURN is only useful for the storage of hashes of data or very small messages.
July 14, 2016, 10:28:43 AM
You can only have a *single* OP_RETURN per tx - so there is no issue with multiple outputs.
The data that follows an OP_RETURN can be safely pruned so it will not be "stored forever" (unlike UTXO data that has to be kept).
The data that follows an OP_RETURN can be safely pruned so it will not be "stored forever" (unlike UTXO data that has to be kept).
It must be stored by archival nodes, and it must be transmitted in full to anything trying to validate entire blocks.
Quote
The entire reason for OP_RETURN is to provide a way where people can store some extra data per tx but which cannot be relied upon to be kept by all nodes.
Because you can only store 80 bytes per tx it isn't a very cheap way to store information and this is why services exist that store hashes for information instead of the information (which would make sense for things like documents).
It's there to provide space for commitments to data (which as you say, will not be stored by all nodes), not explicit data. These services operate this way because that is the least-imposing way to commit to data, and the 80-byte IsStandard restriction is to discourage people from doing other things.Because you can only store 80 bytes per tx it isn't a very cheap way to store information and this is why services exist that store hashes for information instead of the information (which would make sense for things like documents).
Quote
There are no mainnet sidechains even running yet - so recommending people to use such things makes no sense.
I never recommended anybody use a sidechain. Bitcoin has supported pay-to-contract since day one.
July 14, 2016, 09:51:37 AM
You can check out http://cryptograffiti.info to get the idea.
July 14, 2016, 08:59:05 AM
You can only have a *single* OP_RETURN per tx - so there is no issue with multiple outputs.
The data that follows an OP_RETURN can be safely pruned so it will not be "stored forever" (unlike UTXO data that has to be kept).
The entire reason for OP_RETURN is to provide a way where people can store some extra data per tx but which cannot be relied upon to be kept by all nodes.
Because you can only store 80 bytes per tx it isn't a very cheap way to store information and this is why services exist that store hashes for information instead of the information (which would make sense for things like documents).
There are no mainnet sidechains even running yet - so recommending people to use such things makes no sense.
The data that follows an OP_RETURN can be safely pruned so it will not be "stored forever" (unlike UTXO data that has to be kept).
The entire reason for OP_RETURN is to provide a way where people can store some extra data per tx but which cannot be relied upon to be kept by all nodes.
Because you can only store 80 bytes per tx it isn't a very cheap way to store information and this is why services exist that store hashes for information instead of the information (which would make sense for things like documents).
There are no mainnet sidechains even running yet - so recommending people to use such things makes no sense.
July 14, 2016, 06:48:44 AM
Please do not put arbitrary data in OP_RETURN outputs. This is antisocial because you are forcing everybody using the network to indefinitely store (or at least receive) your data, which presumably is (a) relevant only to you and your recipient, and (b) only revelant at the time of the transaction.
How to do this properly depends on your goal:
For timestamping data, I think in the other thread some people mentioned services that bundle up many messages and commit to them all in a single OP_RETURN output. This is much better and (IMHO, as only one participant who is affected by the extra data) perfectly fine. It winds up costing everyone 40 bytes a day or something on this magnitude, regardless of the number of users.
To attach a message to specific transaction, send it out of band and use pay-to-contract to commit to it. This costs zero blockchain space and ensures that your message cannot be changed or corrupted. Unfortunately I'm not aware of any wallet support but the math is very easy (described in Appendix A of the sidechains whitepaper), and is done in contracthashtool and pacthash for use in the sidechain Elements Alpha.
Note that in either case you need to send the message out-of-band, and are only using the blockchain for commitment, timestamping, and associating it to a specific transaction.
How to do this properly depends on your goal:
For timestamping data, I think in the other thread some people mentioned services that bundle up many messages and commit to them all in a single OP_RETURN output. This is much better and (IMHO, as only one participant who is affected by the extra data) perfectly fine. It winds up costing everyone 40 bytes a day or something on this magnitude, regardless of the number of users.
To attach a message to specific transaction, send it out of band and use pay-to-contract to commit to it. This costs zero blockchain space and ensures that your message cannot be changed or corrupted. Unfortunately I'm not aware of any wallet support but the math is very easy (described in Appendix A of the sidechains whitepaper), and is done in contracthashtool and pacthash for use in the sidechain Elements Alpha.
Note that in either case you need to send the message out-of-band, and are only using the blockchain for commitment, timestamping, and associating it to a specific transaction.
July 14, 2016, 06:01:27 AM
There is a thread from last week discussing something similar (or identical) depending on precisely what you are asking:
https://bitcointalksearch.org/topic/sending-a-message-with-a-transactions-1528808
https://bitcointalksearch.org/topic/sending-a-message-with-a-transactions-1528808
Yeah, it really looks identical indeed. And I dont know yet if this is working ? I did not yet experienced receiving transactions with message. I just put some comments when I transfer money but I don't know if it is appearing in the receivers. Anyways it is good to have a message during receiving transactions so that, you can tract whose sending to you or something like that.
I used coinb.in to try this out[1] and it worked pretty well IMO.
[1] https://www.blocktrail.com/BTC/tx/51e688919ee7d901c61513a88a4874e36bb06c31d0384e9781e58ff6a2900058#tx_messages
July 14, 2016, 04:33:12 AM
There is a thread from last week discussing something similar (or identical) depending on precisely what you are asking:
https://bitcointalksearch.org/topic/sending-a-message-with-a-transactions-1528808
https://bitcointalksearch.org/topic/sending-a-message-with-a-transactions-1528808
Yeah, it really looks identical indeed. And I dont know yet if this is working ? I did not yet experienced receiving transactions with message. I just put some comments when I transfer money but I don't know if it is appearing in the receivers. Anyways it is good to have a message during receiving transactions so that, you can tract whose sending to you or something like that.
July 06, 2016, 09:38:56 AM
There is a thread from last week discussing something similar (or identical) depending on precisely what you are asking:
https://bitcointalksearch.org/topic/sending-a-message-with-a-transactions-1528808
https://bitcointalksearch.org/topic/sending-a-message-with-a-transactions-1528808
July 06, 2016, 09:13:05 AM
It is possible to use the OP_RETURN method to add up to 80 arbitrary bytes to a transaction although I'm not sure if any wallets let you easily use this yet.
July 06, 2016, 09:06:49 AM
Hi I wonder if its possible to add messages to a tx, and if its possible to retreive from the blockchain. I know most descriptons on wallets arent really available on the blockchain.
Please let me know if I missed something.
Please let me know if I missed something.
Jump to: