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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1UedH5-0006LW-2b
for bitcoin-development@lists.sourceforge.net;
Tue, 21 May 2013 03:30:07 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.47 as permitted sender)
client-ip=209.85.219.47; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f47.google.com;
Received: from mail-oa0-f47.google.com ([209.85.219.47])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UedH4-0008L1-0W
for bitcoin-development@lists.sourceforge.net;
Tue, 21 May 2013 03:30:07 +0000
Received: by mail-oa0-f47.google.com with SMTP id m1so196154oag.6
for <bitcoin-development@lists.sourceforge.net>;
Mon, 20 May 2013 20:30:00 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.226.162 with SMTP id rt2mr296304obc.9.1369107000658;
Mon, 20 May 2013 20:30:00 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.11.230 with HTTP; Mon, 20 May 2013 20:30:00 -0700 (PDT)
Received: by 10.76.11.230 with HTTP; Mon, 20 May 2013 20:30:00 -0700 (PDT)
In-Reply-To: <CA+8xBpeUOsZq=3jP7GMJgnxH1Vh9GmPydzXWuScCjDyVUf2YVg@mail.gmail.com>
References: <519AB8EB.5000103@monetize.io>
<CA+8xBpeUOsZq=3jP7GMJgnxH1Vh9GmPydzXWuScCjDyVUf2YVg@mail.gmail.com>
Date: Mon, 20 May 2013 20:30:00 -0700
X-Google-Sender-Auth: Z_PiV1h240MUXcGII_abhf9fbpc
Message-ID: <CANEZrP10UpCEKFZiTrnRJxiwJW6tmfZRLJpYzVceew5tXXugaw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jeff Garzik <jgarzik@exmulti.com>
Content-Type: multipart/alternative; boundary=001a11c2e93c6f1a7d04dd3210f3
X-Spam-Score: -0.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1UedH4-0008L1-0W
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: Tue, 21 May 2013 03:30:07 -0000
--001a11c2e93c6f1a7d04dd3210f3
Content-Type: text/plain; charset=UTF-8
Bitcoinj already has such chain id's and we use standard Java style reverse
DNS names: org.bitcoin.main, etc. If we want a more global naming system
that seems like a good compromise between uniqueness and readability.
On 20 May 2013 19:45, "Jeff Garzik" <jgarzik@exmulti.com> wrote:
> On Mon, May 20, 2013 at 7:59 PM, Mark Friedenbach <mark@monetize.io>
> wrote:
> > 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.)
>
> This proposal seems closer to Version 5 than Version 4, in spirit.
> But given that useful content may be deduced from UUID, it is not
> truly applicable to either. A bitcoin-specific version 6, if you
> will.
>
>
> > 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')
>
> Note that, as this example unintentionally implies, humans are going
> to want a side-by-side mapping /anyway/, just to make it readable and
> usable to humans.
>
> Almost all useful multi-chain software will require a readable
> shortname string anyway, the thing this proposal wishes to avoid.
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik@exmulti.com
>
>
> ------------------------------------------------------------------------------
> 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
>
--001a11c2e93c6f1a7d04dd3210f3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Bitcoinj already has such chain id's and we use standard=
Java style reverse DNS names: org.bitcoin.main, etc. If we want a more glo=
bal naming system that seems like a good compromise between uniqueness and =
readability.</p>
<div class=3D"gmail_quote">On 20 May 2013 19:45, "Jeff Garzik" &l=
t;<a href=3D"mailto:jgarzik@exmulti.com">jgarzik@exmulti.com</a>> wrote:=
<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, May 20, 2013 at 7:59 PM, Mark Friedenbach <<a href=3D"mailto:mar=
k@monetize.io">mark@monetize.io</a>> wrote:<br>
> So as to remain reasonably compliant with RFC 4122, I recommend that w=
e<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<b=
r>
> thing about it: adopting this method for identifying chains/coins will=
<br>
> greatly assist in adopting the payment protocol to colored coins.)<br>
<br>
This proposal seems closer to Version 5 than Version 4, in spirit.<br>
But given that useful content may be deduced from UUID, it is not<br>
truly applicable to either. =C2=A0A bitcoin-specific version 6, if you<br>
will.<br>
<br>
<br>
> And some example chain identifiers:<br>
><br>
> =C2=A0 =C2=A0 =C2=A0mainnet: =C2=A0UUID('6fe28c0a-b6f1-4372-81a6-a=
246ae63f74f')<br>
> =C2=A0 =C2=A0 =C2=A0testnet3: UUID('43497fd7-f826-4571-88f4-a30fd9=
cec3ae')<br>
> =C2=A0 =C2=A0 =C2=A0namecoin: UUID('70c7a9f0-a2fb-4d48-a635-a70d5b=
157c80')<br>
<br>
Note that, as this example unintentionally implies, humans are going<br>
to want a side-by-side mapping /anyway/, just to make it readable and<br>
usable to humans.<br>
<br>
Almost all useful multi-chain software will require a readable<br>
shortname string anyway, the thing this proposal wishes to avoid.<br>
<br>
--<br>
Jeff Garzik<br>
exMULTI, Inc.<br>
<a href=3D"mailto:jgarzik@exmulti.com">jgarzik@exmulti.com</a><br>
<br>
---------------------------------------------------------------------------=
---<br>
Try New Relic Now & We'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, & 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>
--001a11c2e93c6f1a7d04dd3210f3--
|
