Re: [Bitcoin-development] Standardizing OP_RETURN message format

[Peter Todd <pete@petertodd.org>]

[-- Attachment #1: Type: text/plain, Size: 2489 bytes --]

On Sun, Apr 06, 2014 at 09:35:20AM +0200, Maciej Trebacz wrote:
> So, OP_RETURN is here and there is no coming back. So if we have it, it
> would be nice to actually make use of it in a good way. I would like to
> write a process BIP with a proposal for standardizing OP_RETURN
> transactions for better interoperability between services. Right now there
> are no guidelines for crafting these transactions, so everyone just does
> what he believes is good for him.
> 
> What I would propose is a common, extensible protocol that can be used by
> anyone. The generic format would be like this:
> 
> OP_RETURN OP_PUSHDATA[length] {2-byte message type} {data}
> 
> So basically, we would have a list of message types, that can be then
> parsed by everyone because the format is open. It could go like this:
> 
> MSG Type | Parameters | Description
> 
> 00 00 | unknown | Unused type, use it if you don't want to share your
> message format with others
> 00 01 | none | Proof of burn transaction. Use it if you want to effectively
> destroy coins (by sending it all as fees to miners)
> ...
> 
> And so on. I have few more ideas for these kind of messages, but it will
> only work if we try to make it an open standard, hence the BIP idea. Can I
> expect that it will be included with other BIPs if I write it?

Why do you want to make it easier for third-parties to determine what
your OP_RETURN messages are for? You want the messages to be
indistinguishable from each other to avoid censorship of them, and give
node operators plausible deniability, just like you want your Bitcoin
transactions to be indistinguishable from each other. Efficient discover
should be done by controlled disambiguation, for instance with the
prefix filtering method. (easily applied to bloom filters as well)

Secondly do not restrict yourself to OP_RETURN - it is far from certain
that it will survive in its present form with the high centralization of
mining we currently have. Note how it was rather arbitrarily reduced
from 80 bytes to 40 bytes, screwing over a number of projects who had
naively written code assuming it would be deployed as promised in the
promised form.

In any case I have better encoding methods for proof-of-publication and
commitments on my TODO list and will be pubishing code and best
practices specifications in the coming weeks.

-- 
'peter'[:-1]@petertodd.org
0000000000000000f4f5ba334791a4102917e4d3f22f6ad7f2c4f15d97307fe2

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 665 bytes --]