11
2
Are some possible ways to embed messages in the blockchain better in some sense than others? What are the important differences?
(Followup on this answer)
What are the key differences between different ways of embedding messages in the blockchain?
Answers
7
There are multiple places one can embed messages in the block chain. Any field that takes arbitrary values can be used.
- Nonce - nonce is a field in the header that can take 4 bytes of data. Not the best place to embed much, but it does not bloat the block size
- Coinbase string - probably the best place to embed messages. It takes an arbitrary length and doesn't have to adhere to any rules. Main problem is that there is only one coinbase string per block, which usually means one would have to mine the block oneself in order to encode the string. Another important thing to note is that one should not use the exact same coinbase string all the time, as it might make the output irredeemable (if the transaction hash is duplicated)
- Transaction outputs - The Tx message outputs can be used to encode messages in the form of output addresses and possibly Bitcoin transfer amounts. This can create irredeemable transactions (if the transfer amount is higher than 0). The overhead of encoding transactions in this way is not too big, in case of 0BTC transactions it would be 10 wasted bytes for about 23 bytes sent (total transaction size is about 33 bytes).
- Transaction script - Probably the best way to encode messages, although it is not widely supported (requires custom transaction script creation). Messages are created by adding two script operations - OP_PushData and OP_Drop in the output script of any transaction, and adding the message body in between the two operations. In order to embed messages in this way one would add just a couple bytes in order to send fairly large body of text.
One could also try creating partial SHA collisions that would encode to some short message, although this method would require a lot of computing, yielding short message encoding.
4
The most correct way is to create a merge-mined message tree.
If you just need a short number (a transaction id, for instance), you can embed it in the transfer itself.
Then there's abuses... these cause excessive bloat the to must-be-stored-forever-by-all-full-nodes blockchain and harm Bitcoin. Please don't do these:
You can embed it as the "address" of a transfer, with a zero-amount output.
btcmsg goes to an extreme and embeds it in the amounts of the transfer.
1You should really explain why you consider anything like that as "Abuse". What do you care what 3rd parties are doing? They are paying the fees or mining the blocks, just like everybody else.
In my book there is no "abuse". Perhaps some ways are better than others in a technical sense, but the word "abuse" implies being morally in the wrong ... what's the moral problem here? – ripper234 – 2012-01-19T08:26:45.323
My post already explained why they are abuses: "these cause excessive bloat the to must-be-stored-forever-by-all-full-nodes blockchain and harm Bitcoin" – Luke-Jr – 2012-01-19T15:08:38.017
Excessive is a matter of interpretation. If the protocol allows it, it's ok by my book. Well, not wasting any more time on this, you say Tomato, I say Tomato. – ripper234 – 2012-01-20T13:15:45.550
2The bitcoin blockchain is a massive beast to maintain. Miners are paid for their efforts to secure it, but all other full nodes in the bitcoin network are not, and collectively they do carry a very large cost in doing so. Their operators voluntarily pay this price, as the cost is outweighed by the benefit: a currency called Bitcoin, which they find valuable. When people start using the blockchain for other purposes however, this cost will increase without further benefit to them, possibly making people less inclined to pay it. – Pieter Wuille – 2012-02-18T13:27:35.960