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 <m...@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?
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
