Bitcoin Forum
April 26, 2024, 06:32:13 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: attaching messages on transactions and retrieving them from the blockchain  (Read 1248 times)
jza (OP)
Full Member
***
Offline Offline

Activity: 126
Merit: 102


View Profile
July 06, 2016, 02:06:49 PM
Merited by ABCbits (2)
 #1

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.
Whoever mines the block which ends up containing your transaction will get its fee.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714156333
Hero Member
*
Offline Offline

Posts: 1714156333

View Profile Personal Message (Offline)

Ignore
1714156333
Reply with quote  #2

1714156333
Report to moderator
1714156333
Hero Member
*
Offline Offline

Posts: 1714156333

View Profile Personal Message (Offline)

Ignore
1714156333
Reply with quote  #2

1714156333
Report to moderator
1714156333
Hero Member
*
Offline Offline

Posts: 1714156333

View Profile Personal Message (Offline)

Ignore
1714156333
Reply with quote  #2

1714156333
Report to moderator
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1075


Ian Knowles - CIYAM Lead Developer


View Profile WWW
July 06, 2016, 02:13:05 PM
Last edit: July 06, 2016, 03:15:26 PM by CIYAM
Merited by ABCbits (2)
 #2

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.

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
cr1776
Legendary
*
Offline Offline

Activity: 4018
Merit: 1299


View Profile
July 06, 2016, 02:38:56 PM
 #3

There is a thread from last week discussing something similar (or identical) depending on precisely what you are asking:

https://bitcointalk.org/index.php?topic=1528808.0
LucioTan
Full Member
***
Offline Offline

Activity: 224
Merit: 100



View Profile
July 14, 2016, 09:33:12 AM
 #4

There is a thread from last week discussing something similar (or identical) depending on precisely what you are asking:

https://bitcointalk.org/index.php?topic=1528808.0


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.
ranochigo
Legendary
*
Offline Offline

Activity: 2954
Merit: 4165


View Profile
July 14, 2016, 11:01:27 AM
 #5

There is a thread from last week discussing something similar (or identical) depending on precisely what you are asking:

https://bitcointalk.org/index.php?topic=1528808.0


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.
For most wallets, the comments are stored locally and hence the receiver can't see it and you won't be able to if you don't get the correct backup back. For starters, Blockchain.info does have the feature of including a message that is only visible on their wallet service which means that they can control what message can be placed. OP_Return is another method just as the people above mentioned, AFAIK, most wallets don't display the hex or the message yet but some blockexplorers do.

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

.
.HUGE.
▄██████████▄▄
▄█████████████████▄
▄█████████████████████▄
▄███████████████████████▄
▄█████████████████████████▄
███████▌██▌▐██▐██▐████▄███
████▐██▐████▌██▌██▌██▌██
█████▀███▀███▀▐██▐██▐█████

▀█████████████████████████▀

▀███████████████████████▀

▀█████████████████████▀

▀█████████████████▀

▀██████████▀▀
█▀▀▀▀











█▄▄▄▄
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
.
CASINSPORTSBOOK
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
▀▀▀▀█











▄▄▄▄█
andytoshi
Full Member
***
Offline Offline

Activity: 179
Merit: 151

-


View Profile
July 14, 2016, 11:48:44 AM
 #6

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.
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1075


Ian Knowles - CIYAM Lead Developer


View Profile WWW
July 14, 2016, 01:59:05 PM
Merited by ABCbits (1)
 #7

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.

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
Hyena
Legendary
*
Offline Offline

Activity: 2114
Merit: 1011



View Profile WWW
July 14, 2016, 02:51:37 PM
 #8

You can check out http://cryptograffiti.info to get the idea.

★★★ CryptoGraffiti.info ★★★ Hidden Messages Found from the Block Chain (Thread)
andytoshi
Full Member
***
Offline Offline

Activity: 179
Merit: 151

-


View Profile
July 14, 2016, 03:28:43 PM
 #9

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

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.

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.
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1075


Ian Knowles - CIYAM Lead Developer


View Profile WWW
July 14, 2016, 03:50:02 PM
 #10

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.

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
jza (OP)
Full Member
***
Offline Offline

Activity: 126
Merit: 102


View Profile
July 14, 2016, 11:01:13 PM
 #11

Right, there are altcoins like Sia and StorJ for those.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!