1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
|
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 <pete@petertodd.org>) 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 <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)
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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--
|
