From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WWkT2-0008I8-Px for bitcoin-development@lists.sourceforge.net; Sun, 06 Apr 2014 10:38:24 +0000 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; Received: from outmail149058.authsmtp.co.uk ([62.13.149.58]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WWkT1-0003Mo-L1 for bitcoin-development@lists.sourceforge.net; Sun, 06 Apr 2014 10:38:24 +0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt14.authsmtp.com (8.14.2/8.14.2) with ESMTP id s36AcEXY072947; Sun, 6 Apr 2014 11:38:14 +0100 (BST) Received: from tilt ([195.96.78.12]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s36Abmoi062590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 6 Apr 2014 11:38:06 +0100 (BST) Date: Sun, 6 Apr 2014 12:37:32 +0200 From: Peter Todd To: Maciej Trebacz Message-ID: <20140406103732.GA3279@tilt> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 8da70a2f-bd77-11e3-94fa-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdgQUGUUGAgsB AmIbWlVeU1V7WGE7 agNUcwxbfE1GQQRo T01BRU1TWkZrB21T W0FHUh9wcgxGNn9y ZERkEHgPDUN6JEQr XxwAEmobZGY1a30W VBYJagNUcgZDfk5E aVUrVz1vNG8XDQg5 AwQ0PjZ0MThBJSBS WgQAK04nCX0XFzgw TgoOHCcuG0JNYB0E FTEaF2Q6VEMcKV47 PlZpV1UCNhYOYgAA X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 195.96.78.12/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1WWkT1-0003Mo-L1 Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Standardizing OP_RETURN message format X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 10:38:24 -0000 --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--