1  Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
  2  	helo=mx.sourceforge.net)
  3  	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
  4  	(envelope-from <mark@monetize.io>) id 1UeeEn-0003wT-PG
  5  	for bitcoin-development@lists.sourceforge.net;
  6  	Tue, 21 May 2013 04:31:49 +0000
  7  Received: from mail-pa0-f49.google.com ([209.85.220.49])
  8  	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
  9  	(Exim 4.76) id 1UeeEk-0000mO-G5
 10  	for bitcoin-development@lists.sourceforge.net;
 11  	Tue, 21 May 2013 04:31:49 +0000
 12  Received: by mail-pa0-f49.google.com with SMTP id bi5so290733pad.36
 13  	for <bitcoin-development@lists.sourceforge.net>;
 14  	Mon, 20 May 2013 21:31:40 -0700 (PDT)
 15  X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 16  	d=google.com; s=20120113;
 17  	h=message-id:date:from:organization:user-agent:mime-version:to:cc
 18  	:subject:references:in-reply-to:content-type
 19  	:content-transfer-encoding:x-gm-message-state;
 20  	bh=HXTXLOlnoeRg2NzwJq5C/sFFjy/5zoDnFoL2DSEb2O4=;
 21  	b=WPlHspAT4C5mRfHaBahiiytQAddQeEf20JATazKbGNydk+g2pA5gKoU2S+YFDZjaWp
 22  	DZoUXhVtj9CrmNVbWJmUl1eeugfNi304Z5MaXmY+Xh9AeYZdCcN1mbh4gKCngZy29dXI
 23  	tiKSPfx605AXSO1oSqMa9XJcZzoUeIjN+6kuFrKr/LmEuZYa1N61bnCWd9k5ibtaJY7x
 24  	gu8hrTVlo7uWDz8JZYOK2kj3sXco7on7Re7igFKQxxnolRMho4SWfoEIYgzd9+moTeeC
 25  	6svCBmmfyRer2Me9IbxX3lfyeTsOwlmzeHHFp5zRa5pffKsAUiPowH+wCEpAVnqpV+ZI
 26  	BjOQ==
 27  X-Received: by 10.67.2.33 with SMTP id bl1mr1219297pad.26.1369108846896;
 28  	Mon, 20 May 2013 21:00:46 -0700 (PDT)
 29  Received: from phobos.local (50-0-36-146.dsl.dynamic.sonic.net. [50.0.36.146])
 30  	by mx.google.com with ESMTPSA id
 31  	fp2sm852006pbb.36.2013.05.20.21.00.45 for <multiple recipients>
 32  	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 33  	Mon, 20 May 2013 21:00:46 -0700 (PDT)
 34  Message-ID: <519AF16C.3040005@monetize.io>
 35  Date: Mon, 20 May 2013 21:00:44 -0700
 36  From: Mark Friedenbach <mark@monetize.io>
 37  Organization: Monetize.io Inc.
 38  User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 39  	rv:17.0) Gecko/20130509 Thunderbird/17.0.6
 40  MIME-Version: 1.0
 41  To: Jeff Garzik <jgarzik@exmulti.com>
 42  References: <519AB8EB.5000103@monetize.io>
 43  	<CA+8xBpeUOsZq=3jP7GMJgnxH1Vh9GmPydzXWuScCjDyVUf2YVg@mail.gmail.com>
 44  In-Reply-To: <CA+8xBpeUOsZq=3jP7GMJgnxH1Vh9GmPydzXWuScCjDyVUf2YVg@mail.gmail.com>
 45  Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 46  Content-Transfer-Encoding: 7bit
 47  X-Gm-Message-State: ALoCoQnt/O5tWp2AlRCeJVFRfmMAX1v4lM1neoZ5i+0f2AJP/5nDdOa0CThcOQJ2v/e0WIiYMGMq
 48  X-Spam-Score: 0.0 (/)
 49  X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
 50  	See http://spamassassin.org/tag/ for more details.
 51  X-Headers-End: 1UeeEk-0000mO-G5
 52  Cc: bitcoin-development@lists.sourceforge.net
 53  Subject: Re: [Bitcoin-development] UUID to identify chains (payment protocol
 54   and elsewhere)
 55  X-BeenThere: bitcoin-development@lists.sourceforge.net
 56  X-Mailman-Version: 2.1.9
 57  Precedence: list
 58  List-Id: <bitcoin-development.lists.sourceforge.net>
 59  List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
 60  	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
 61  List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
 62  List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
 63  List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
 64  List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
 65  	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
 66  X-List-Received-Date: Tue, 21 May 2013 04:31:50 -0000
 67  
 68  This was meant to go to everyone:
 69  
 70  On 5/20/13 7:45 PM, Jeff Garzik wrote:
 71  > On Mon, May 20, 2013 at 7:59 PM, Mark Friedenbach <mark@monetize.io> wrote:
 72  >> So as to remain reasonably compliant with RFC 4122, I recommend that we
 73  >> use Version 4 (random) UUIDs, with the random bits extracted from the
 74  >> double-SHA256 hash of the genesis block of the chain. (For colored
 75  >> coins, the colored coin definition transaction would be used instead,
 76  >> but I will address that in a separate proposal and will say just one
 77  >> thing about it: adopting this method for identifying chains/coins will
 78  >> greatly assist in adopting the payment protocol to colored coins.)
 79  > This proposal seems closer to Version 5 than Version 4, in spirit.
 80  > But given that useful content may be deduced from UUID, it is not
 81  > truly applicable to either.  A bitcoin-specific version 6, if you
 82  > will.
 83  That is true, and perhaps we have enough clout to push an RFC specifying 
 84  a double-SHA256 Version 6, or at least get it reserved. I proposed 
 85  Version 4 (random) because any UUID library should allow you to specify 
 86  the 122 supposedly random bits of that version, whereas conceivably 
 87  there might exist UUID libraries that require a SHA1 pre-image to create 
 88  a Version 5 UUID (I know of no examples though). Regardless, making an 
 89  official double-SHA256 UUID version RFC is an option worth considering.
 90  > And some example chain identifiers:
 91  >
 92  >       mainnet:  UUID('6fe28c0a-b6f1-4372-81a6-a246ae63f74f')
 93  >       testnet3: UUID('43497fd7-f826-4571-88f4-a30fd9cec3ae')
 94  >       namecoin: UUID('70c7a9f0-a2fb-4d48-a635-a70d5b157c80')
 95  > Note that, as this example unintentionally implies, humans are going
 96  > to want a side-by-side mapping /anyway/, just to make it readable and
 97  > usable to humans.
 98  >
 99  > Almost all useful multi-chain software will require a readable
100  > shortname string anyway, the thing this proposal wishes to avoid.
101  I think there are perhaps two issues being conflated here (and in Mike's 
102  response): the UI identifying the network/coin to the user, and the 
103  matching of the protocol-supplied value to the underlying network/coin 
104  by the client/daemon. The former necessarily involves manual adjustments 
105  (e.g, localization), but it's preferable for the latter to be a 
106  self-validating reference to the block chain. This is a trivial 
107  difference for multi-chain wallets (what are you doing receiving 
108  requests for coins in chains you don't know about?), but is important 
109  for colored coins. Let me explain:
110  
111  I will be proposing soon a colored coin architecture that allows 
112  issuance of new coins by anyone for a fee, by means of a special 
113  category of transaction. The hash of that issuing transaction would then 
114  be used to generate a UUID identifying the asset for the payment 
115  protocol and other purposes as well, analogous to how the hash of the 
116  genesis block identifies the host currency, bitcoin. It is expected that 
117  there will be many such coins issued, as they can be used to represent 
118  individual loans or lines of credit. In this context, any colored-coin 
119  aware client could scan the block chain (or lookup a maintained index) 
120  to discover the UUID -> coin mapping with absolute certainty. However 
121  the mechanism for mapping the text "mtgoxUSD" to a specific coin is not 
122  clear, and using some sort of DNS-resolution system adds huge external 
123  dependencies. IMHO it is much better to have the identifier derived from 
124  block chain data directly (and therefore accessible and trusted by all 
125  nodes), and then carry out optional UI mappings like UUID(...) -> 
126  "mtgoxUSD" at a higher level.
127  
128  Does that make sense?
129  
130