Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)

[Mark Friedenbach <mark@monetize.io>]

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?