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?
next prev 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 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$(echo .)io \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jgarzik@exmulti$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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