* [Bitcoin-development] Standardizing OP_RETURN message format
@ 2014-04-06 7:35 Maciej Trebacz
2014-04-06 9:21 ` Gregory Maxwell
2014-04-06 10:37 ` Peter Todd
0 siblings, 2 replies; 3+ messages in thread
From: Maciej Trebacz @ 2014-04-06 7:35 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]
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?
--
Best regards,
Maciej Trębacz - Bitalo.com
[-- Attachment #2: Type: text/html, Size: 1451 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [Bitcoin-development] Standardizing OP_RETURN message format
2014-04-06 7:35 [Bitcoin-development] Standardizing OP_RETURN message format Maciej Trebacz
@ 2014-04-06 9:21 ` Gregory Maxwell
2014-04-06 10:37 ` Peter Todd
1 sibling, 0 replies; 3+ messages in thread
From: Gregory Maxwell @ 2014-04-06 9:21 UTC (permalink / raw)
To: Maciej Trebacz; +Cc: Bitcoin Development
On Sun, Apr 6, 2014 at 12:35 AM, Maciej Trebacz <maciej@bitalo•com> wrote:
> 00 01 | none | Proof of burn transaction. Use it if you want to effectively
> destroy coins (by sending it all as fees to miners)
For just having a dummy output for an all fee transaction you do not
need to have a PUSH at all.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bitcoin-development] Standardizing OP_RETURN message format
2014-04-06 7:35 [Bitcoin-development] Standardizing OP_RETURN message format Maciej Trebacz
2014-04-06 9:21 ` Gregory Maxwell
@ 2014-04-06 10:37 ` Peter Todd
1 sibling, 0 replies; 3+ messages in thread
From: Peter Todd @ 2014-04-06 10:37 UTC (permalink / raw)
To: Maciej Trebacz; +Cc: bitcoin-development
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-04-06 10:38 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-06 7:35 [Bitcoin-development] Standardizing OP_RETURN message format Maciej Trebacz
2014-04-06 9:21 ` Gregory Maxwell
2014-04-06 10:37 ` Peter Todd
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox