Skip to content
Andrew K edited this page Jan 8, 2019 · 4 revisions

The standard way to imbed data into the blockchain is to create an output of the form OP_RETURN <some data>. But if we want to be able to comment on existing data, or to comment on comments (creating a thread), we need some way to reference the txid and ouput number of the data or the comment. For this purpose, we propose adding an operator OP_COMMENT that takes 1 to 3 parameters.

If there is only one parameter, this parameter is the comment (max 255 characters), and the txid is assumed to be the txid containing the comment, and no particular output is being commented on in this case (just the transaction as a whole).

If there are 2 parameters, then the first parameter is the txid (32 bytes) and the second parameter is the comment (max 255 characters).

If there are 3 parameters, the first parameter is the txid (32 bytes), the second is the output number (max 64 bits integer), and the third is the comment (max 255 characters).

So in general, the output has the form: <txid> <nOutput> <comment> OP_COMMENT. The script interpreter pushes the first (up to 3) constants onto the stack, and OP_COMMENT operates on them. We can enforce the particular rules of OP_COMMENT in the validation process, or we can be less strict and just create a relay policy that doesn't relay surface level blocks that don't follow the rules, or we can just make the rules an optional convention that communities that use Bitmark can subscribe to. The nValue should always be 0 to make sure this output is not spendable. Tips can be given through a traditional output including the address to tip to (pay to pubkey hash), and even referenced with comments.

In the future, we can even use OP_COMMENT to comment on transactions and outputs from other non-Bitmark blockchains. This would require clear ways to define a foreign blockchain through it's genesis block and mining algo.