Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.149.58 as permitted sender)
	client-ip=62.13.149.58; envelope-from=pete@petertodd.org;
	helo=outmail149058.authsmtp.co.uk; 
Date: Sun, 6 Apr 2014 12:37:32 +0200
From: Peter Todd <pete@petertodd.org>
To: Maciej Trebacz <maciej@bitalo.com>
Message-ID: <20140406103732.GA3279@tilt>
References: <CAD=_8RSn+ZtxJL1=3BsaEvfc4Wrg7MW-uDTcnQo75GQbrVP3Ng@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi"
Content-Disposition: inline
In-Reply-To: <CAD=_8RSn+ZtxJL1=3BsaEvfc4Wrg7MW-uDTcnQo75GQbrVP3Ng@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Standardizing OP_RETURN message format
Precedence: list


--6c2NcOVqGQ03X4Wi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
>=20
> What I would propose is a common, extensible protocol that can be used by
> anyone. The generic format would be like this:
>=20
> OP_RETURN OP_PUSHDATA[length] {2-byte message type} {data}
>=20
> 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:
>=20
> MSG Type | Parameters | Description
>=20
> 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 effective=
ly
> destroy coins (by sending it all as fees to miners)
> ...
>=20
> 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
=66rom 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.

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

--6c2NcOVqGQ03X4Wi
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQGcBAEBCAAGBQJTQS5oAAoJEGJeboN5AaHKZI0L/2CkdtzrIsYiqU0yx0rCRlAU
ZTIDxB4PTDpyguVyAMHVPc455XpFXUjvO4a6oYz371avcj0YFRGv1XUUMA0zh6Jm
qOp94+wZfHSwu0pS8jNctgBqFmO0XITZSkGHkxqaTU60TtuVdPkeZjAeGqxNZNT0
FFDlQqq6UPCku0eqgtq+nNrQhC3kQMAM+Nf3yixp/ogTw/qZKgcFyl09U+eJvFCF
03xyotUNpKUr1boiGwFTE/FwoeMyBJ/9cvARoYX1JC5EsT0HEG9q4YB2yMSJDXAB
E7SylEWojmGGtH2lXJa46P1CwOE+aL6UDI1/iUjgP9qihLGz2vGFovmjO0BN55cx
ra63XmJsRlnH1wrk9ekzmfd7fiElIAGyYxAYzExOrHVH/TAwoCOqT7Vw/sxUv2vn
1rtZV5kTJjphfHhIb/JdmnAQBpQjzN7HG7svCpImV47tjAXRdypL6KKnmNy02HDT
NbIBnH5jc3G2iXwPLIlcyHgxn3cjwOk1mn5eZ95K4Q==
=XC+9
-----END PGP SIGNATURE-----

--6c2NcOVqGQ03X4Wi--