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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mark@monetize.io>) id 1UeeEn-0003wT-PG
for bitcoin-development@lists.sourceforge.net;
Tue, 21 May 2013 04:31:49 +0000
Received: from mail-pa0-f49.google.com ([209.85.220.49])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UeeEk-0000mO-G5
for bitcoin-development@lists.sourceforge.net;
Tue, 21 May 2013 04:31:49 +0000
Received: by mail-pa0-f49.google.com with SMTP id bi5so290733pad.36
for <bitcoin-development@lists.sourceforge.net>;
Mon, 20 May 2013 21:31:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=message-id:date:from:organization:user-agent:mime-version:to:cc
:subject:references:in-reply-to:content-type
:content-transfer-encoding:x-gm-message-state;
bh=HXTXLOlnoeRg2NzwJq5C/sFFjy/5zoDnFoL2DSEb2O4=;
b=WPlHspAT4C5mRfHaBahiiytQAddQeEf20JATazKbGNydk+g2pA5gKoU2S+YFDZjaWp
DZoUXhVtj9CrmNVbWJmUl1eeugfNi304Z5MaXmY+Xh9AeYZdCcN1mbh4gKCngZy29dXI
tiKSPfx605AXSO1oSqMa9XJcZzoUeIjN+6kuFrKr/LmEuZYa1N61bnCWd9k5ibtaJY7x
gu8hrTVlo7uWDz8JZYOK2kj3sXco7on7Re7igFKQxxnolRMho4SWfoEIYgzd9+moTeeC
6svCBmmfyRer2Me9IbxX3lfyeTsOwlmzeHHFp5zRa5pffKsAUiPowH+wCEpAVnqpV+ZI
BjOQ==
X-Received: by 10.67.2.33 with SMTP id bl1mr1219297pad.26.1369108846896;
Mon, 20 May 2013 21:00:46 -0700 (PDT)
Received: from phobos.local (50-0-36-146.dsl.dynamic.sonic.net. [50.0.36.146])
by mx.google.com with ESMTPSA id
fp2sm852006pbb.36.2013.05.20.21.00.45 for <multiple recipients>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Mon, 20 May 2013 21:00:46 -0700 (PDT)
Message-ID: <519AF16C.3040005@monetize.io>
Date: Mon, 20 May 2013 21:00:44 -0700
From: Mark Friedenbach <mark@monetize.io>
Organization: Monetize.io Inc.
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Jeff Garzik <jgarzik@exmulti.com>
References: <519AB8EB.5000103@monetize.io>
<CA+8xBpeUOsZq=3jP7GMJgnxH1Vh9GmPydzXWuScCjDyVUf2YVg@mail.gmail.com>
In-Reply-To: <CA+8xBpeUOsZq=3jP7GMJgnxH1Vh9GmPydzXWuScCjDyVUf2YVg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQnt/O5tWp2AlRCeJVFRfmMAX1v4lM1neoZ5i+0f2AJP/5nDdOa0CThcOQJ2v/e0WIiYMGMq
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1UeeEk-0000mO-G5
Cc: 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 04:31:50 -0000
This was meant to go to everyone:
On 5/20/13 7:45 PM, Jeff Garzik 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.
That is true, and perhaps we have enough clout to push an RFC specifying
a double-SHA256 Version 6, or at least get it reserved. I proposed
Version 4 (random) because any UUID library should allow you to specify
the 122 supposedly random bits of that version, whereas conceivably
there might exist UUID libraries that require a SHA1 pre-image to create
a Version 5 UUID (I know of no examples though). Regardless, making an
official double-SHA256 UUID version RFC is an option worth considering.
> 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.
I think there are perhaps two issues being conflated here (and in Mike's
response): the UI identifying the network/coin to the user, and the
matching of the protocol-supplied value to the underlying network/coin
by the client/daemon. The former necessarily involves manual adjustments
(e.g, localization), but it's preferable for the latter to be a
self-validating reference to the block chain. This is a trivial
difference for multi-chain wallets (what are you doing receiving
requests for coins in chains you don't know about?), but is important
for colored coins. Let me explain:
I will be proposing soon a colored coin architecture that allows
issuance of new coins by anyone for a fee, by means of a special
category of transaction. The hash of that issuing transaction would then
be used to generate a UUID identifying the asset for the payment
protocol and other purposes as well, analogous to how the hash of the
genesis block identifies the host currency, bitcoin. It is expected that
there will be many such coins issued, as they can be used to represent
individual loans or lines of credit. In this context, any colored-coin
aware client could scan the block chain (or lookup a maintained index)
to discover the UUID -> coin mapping with absolute certainty. However
the mechanism for mapping the text "mtgoxUSD" to a specific coin is not
clear, and using some sort of DNS-resolution system adds huge external
dependencies. IMHO it is much better to have the identifier derived from
block chain data directly (and therefore accessible and trusted by all
nodes), and then carry out optional UI mappings like UUID(...) ->
"mtgoxUSD" at a higher level.
Does that make sense?
|
