public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mark Friedenbach <mark@monetize.io>
To: Jeff Garzik <jgarzik@exmulti.com>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)
Date: Mon, 20 May 2013 21:00:44 -0700	[thread overview]
Message-ID: <519AF16C.3040005@monetize.io> (raw)
In-Reply-To: <CA+8xBpeUOsZq=3jP7GMJgnxH1Vh9GmPydzXWuScCjDyVUf2YVg@mail.gmail.com>

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?



  parent reply	other threads:[~2013-05-21  4:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-20 23:59 [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere) Mark Friedenbach
2013-05-21  2:45 ` Jeff Garzik
2013-05-21  3:30   ` Mike Hearn
2013-05-21  4:00   ` Mark Friedenbach [this message]
2013-05-21  4:04 ` Luke-Jr
2013-05-22 10:27 ` Melvin Carvalho
2013-05-22 14:07   ` Jeff Garzik
2013-05-22 14:12     ` Melvin Carvalho
2013-05-22 14:20       ` Jeff Garzik
2013-05-22 14:29         ` Luke-Jr
2013-05-22 14:55           ` Jeff Garzik
2013-05-22 15:59             ` Gavin Andresen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=519AF16C.3040005@monetize.io \
    --to=mark@monetize.io \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=jgarzik@exmulti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox