summaryrefslogtreecommitdiff
path: root/dd/5dce90573d6d4abe9bc8f3b06a3814090782cf
blob: 1bb253cbf33f53ef25b3e59d9d57a588de8cbfa0 (plain)
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
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <melvincarvalho@gmail.com>) id 1Uf6H3-0001Nw-W3
	for bitcoin-development@lists.sourceforge.net;
	Wed, 22 May 2013 10:28:02 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.217.182 as permitted sender)
	client-ip=209.85.217.182; envelope-from=melvincarvalho@gmail.com;
	helo=mail-lb0-f182.google.com; 
Received: from mail-lb0-f182.google.com ([209.85.217.182])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Uf6H2-0003an-Da
	for bitcoin-development@lists.sourceforge.net;
	Wed, 22 May 2013 10:28:01 +0000
Received: by mail-lb0-f182.google.com with SMTP id z5so1881989lbh.27
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 22 May 2013 03:27:53 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.121.9 with SMTP id lg9mr3534266lab.39.1369218473655;
	Wed, 22 May 2013 03:27:53 -0700 (PDT)
Received: by 10.112.143.38 with HTTP; Wed, 22 May 2013 03:27:53 -0700 (PDT)
In-Reply-To: <519AB8EB.5000103@monetize.io>
References: <519AB8EB.5000103@monetize.io>
Date: Wed, 22 May 2013 12:27:53 +0200
Message-ID: <CAKaEYh+eYEApCnbLPZ12RW1XO41epTR4R_nqxM9c3GFHPDEQig@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Mark Friedenbach <mark@monetize.io>
Content-Type: multipart/alternative; boundary=089e0117749dbe041a04dd4c0415
X-Spam-Score: -0.6 (/)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(melvincarvalho[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Uf6H2-0003an-Da
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] UUID to identify chains (payment protocol
 and elsewhere)
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: Wed, 22 May 2013 10:28:02 -0000

--089e0117749dbe041a04dd4c0415
Content-Type: text/plain; charset=ISO-8859-1

On 21 May 2013 01:59, Mark Friedenbach <mark@monetize.io> wrote:

> At the developer round-table it was asked if the payment protocol would
> alt-chains, and Gavin noted that it has a UTF-8 encoded string
> identifying the network ("main" or "test"). As someone with two
> proposals in the works which also require chain/coin identification (one
> for merged mining, one for colored coins), I am opinionated on this. I
> believe that we need a standard mechanism for identifying chains, and
> one which avoids the trap of maintaining a standard registry of
> string-to-chain mappings.
>
> Any chain can be uniquely identified by its genesis block, 122 random
> bits is more than sufficient for uniquely tagging chains/colored assets,
> and the low-order 16-bytes of the block's hash are effectively random.
> With these facts in mind, I propose that we identify chains by UUID.
>
> So as to remain reasonably compliant with RFC 4122, I recommend that we
> use Version 4 (random) UUIDs, with the random bits extracted from the
> double-SHA256 hash of the genesis block of the chain. (For colored
> coins, the colored coin definition transaction would be used instead,
> but I will address that in a separate proposal and will say just one
> thing about it: adopting this method for identifying chains/coins will
> greatly assist in adopting the payment protocol to colored coins.)
>
> The following Python code illustrates how to construct the chain
> identifier from the serialized genesis block:
>
>      from hashlib import sha256
>      from uuid import UUID
>      def chain_uuid(serialized_genesis_block):
>          h = sha256(serialized_genesis_block).digest()
>          h = sha256(h).digest()
>          h = h[:16]
>          h = ''.join([
>              h[:6],
>              chr(0x40 | ord(h[6]) & 0x0f),
>              h[7],
>              chr(0x80 | ord(h[8]) & 0x3f),
>              h[9:]
>          ])
>          return UUID(bytes=h)
>
> And some example chain identifiers:
>
>      mainnet:  UUID('6fe28c0a-b6f1-4372-81a6-a246ae63f74f')
>      testnet3: UUID('43497fd7-f826-4571-88f4-a30fd9cec3ae')
>      namecoin: UUID('70c7a9f0-a2fb-4d48-a635-a70d5b157c80')
>
> As for encoding the chain identifier, the simplest method is to give
> "network" the "bytes" type, but defining a "UUID" message type is also
> possible. In either case bitcoin mainnet would be the default, so the
> extra 12 bytes (vs: "main" or "test") would only be an issue for
> alt-chains or colored coins.
>

This is essentially name spacing.  As registries grow namespaces become
more important.  In bitcoin's quest for decentrality there's also the
question of who maintains the registry.

Some out of band algo/hash could work so long as there was a one to one
relationship between the described object and the UUID.  In this case the
gensis block may not uniquely identify a coin.

The normal way to namespace a registry on the internet is to allow it to be
a URI.  In this case an http style uri has the added bonus side effect that
it can be dereferencable and both human and machine readable.  So yes
something like org.bitcoin.* is good, just simply growing things to http
style uris is cleaner, imho


>
> Kind regards,
> Mark Friedenbach
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--089e0117749dbe041a04dd4c0415
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 21 May 2013 01:59, Mark Friedenbach <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:mark@monetize.io" target=3D"_blank">mark@monetize.io</a>&gt;</s=
pan> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">At the developer round-table it was asked if=
 the payment protocol would<br>
alt-chains, and Gavin noted that it has a UTF-8 encoded string<br>
identifying the network (&quot;main&quot; or &quot;test&quot;). As someone =
with two<br>
proposals in the works which also require chain/coin identification (one<br=
>
for merged mining, one for colored coins), I am opinionated on this. I<br>
believe that we need a standard mechanism for identifying chains, and<br>
one which avoids the trap of maintaining a standard registry of<br>
string-to-chain mappings.<br>
<br>
Any chain can be uniquely identified by its genesis block, 122 random<br>
bits is more than sufficient for uniquely tagging chains/colored assets,<br=
>
and the low-order 16-bytes of the block&#39;s hash are effectively random.<=
br>
With these facts in mind, I propose that we identify chains by UUID.<br>
<br>
So as to remain reasonably compliant with RFC 4122, I recommend that we<br>
use Version 4 (random) UUIDs, with the random bits extracted from the<br>
double-SHA256 hash of the genesis block of the chain. (For colored<br>
coins, the colored coin definition transaction would be used instead,<br>
but I will address that in a separate proposal and will say just one<br>
thing about it: adopting this method for identifying chains/coins will<br>
greatly assist in adopting the payment protocol to colored coins.)<br>
<br>
The following Python code illustrates how to construct the chain<br>
identifier from the serialized genesis block:<br>
<br>
=A0 =A0 =A0from hashlib import sha256<br>
=A0 =A0 =A0from uuid import UUID<br>
=A0 =A0 =A0def chain_uuid(serialized_genesis_block):<br>
=A0 =A0 =A0 =A0 =A0h =3D sha256(serialized_genesis_block).digest()<br>
=A0 =A0 =A0 =A0 =A0h =3D sha256(h).digest()<br>
=A0 =A0 =A0 =A0 =A0h =3D h[:16]<br>
=A0 =A0 =A0 =A0 =A0h =3D &#39;&#39;.join([<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0h[:6],<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0chr(0x40 | ord(h[6]) &amp; 0x0f),<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0h[7],<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0chr(0x80 | ord(h[8]) &amp; 0x3f),<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0h[9:]<br>
=A0 =A0 =A0 =A0 =A0])<br>
=A0 =A0 =A0 =A0 =A0return UUID(bytes=3Dh)<br>
<br>
And some example chain identifiers:<br>
<br>
=A0 =A0 =A0mainnet: =A0UUID(&#39;6fe28c0a-b6f1-4372-81a6-a246ae63f74f&#39;)=
<br>
=A0 =A0 =A0testnet3: UUID(&#39;43497fd7-f826-4571-88f4-a30fd9cec3ae&#39;)<b=
r>
=A0 =A0 =A0namecoin: UUID(&#39;70c7a9f0-a2fb-4d48-a635-a70d5b157c80&#39;)<b=
r>
<br>
As for encoding the chain identifier, the simplest method is to give<br>
&quot;network&quot; the &quot;bytes&quot; type, but defining a &quot;UUID&q=
uot; message type is also<br>
possible. In either case bitcoin mainnet would be the default, so the<br>
extra 12 bytes (vs: &quot;main&quot; or &quot;test&quot;) would only be an =
issue for<br>
alt-chains or colored coins.<br></blockquote><div><br></div><div>This is es=
sentially name spacing.=A0 As registries grow namespaces become more import=
ant.=A0 In bitcoin&#39;s quest for decentrality there&#39;s also the questi=
on of who maintains the registry.<br>
<br></div><div>Some out of band algo/hash could work so long as there was a=
 one to one relationship between the described object and the UUID.=A0 In t=
his case the gensis block may not uniquely identify a coin.<br><br></div>
<div>The normal way to namespace a registry on the internet is to allow it =
to be a URI.=A0 In this case an http style uri has the added bonus side eff=
ect that it can be dereferencable and both human and machine readable.=A0 S=
o yes something like org.bitcoin.* is good, just simply growing things to h=
ttp style uris is cleaner, imho<br>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Kind regards,<br>
Mark Friedenbach<br>
<br>
---------------------------------------------------------------------------=
---<br>
Try New Relic Now &amp; We&#39;ll Send You this Cool Shirt<br>
New Relic is the only SaaS-based application performance monitoring service=
<br>
that delivers powerful full stack analytics. Optimize and monitor your<br>
browser, app, &amp; servers with just a few lines of code. Try New Relic<br=
>
and get this awesome Nerd Life shirt! <a href=3D"http://p.sf.net/sfu/newrel=
ic_d2d_may" target=3D"_blank">http://p.sf.net/sfu/newrelic_d2d_may</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div><br></div></div>

--089e0117749dbe041a04dd4c0415--