From: Melvin Carvalho <melvincarvalho@gmail•com>
To: Mark Friedenbach <mark@monetize•io>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)
Date: Wed, 22 May 2013 12:27:53 +0200 [thread overview]
Message-ID: <CAKaEYh+eYEApCnbLPZ12RW1XO41epTR4R_nqxM9c3GFHPDEQig@mail.gmail.com> (raw)
In-Reply-To: <519AB8EB.5000103@monetize.io>
[-- Attachment #1: Type: text/plain, Size: 3870 bytes --]
On 21 May 2013 01:59, Mark Friedenbach <mark@monetize•io> wrote:
> At the developer round-table it was asked if the payment protocol would
> alt-chains, and Gavin noted that it has a UTF-8 encoded string
> identifying the network ("main" or "test"). As someone with two
> proposals in the works which also require chain/coin identification (one
> for merged mining, one for colored coins), I am opinionated on this. I
> believe that we need a standard mechanism for identifying chains, and
> one which avoids the trap of maintaining a standard registry of
> string-to-chain mappings.
>
> Any chain can be uniquely identified by its genesis block, 122 random
> bits is more than sufficient for uniquely tagging chains/colored assets,
> and the low-order 16-bytes of the block's hash are effectively random.
> With these facts in mind, I propose that we identify chains by UUID.
>
> 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.)
>
> The following Python code illustrates how to construct the chain
> identifier from the serialized genesis block:
>
> from hashlib import sha256
> from uuid import UUID
> def chain_uuid(serialized_genesis_block):
> h = sha256(serialized_genesis_block).digest()
> h = sha256(h).digest()
> h = h[:16]
> h = ''.join([
> h[:6],
> chr(0x40 | ord(h[6]) & 0x0f),
> h[7],
> chr(0x80 | ord(h[8]) & 0x3f),
> h[9:]
> ])
> return UUID(bytes=h)
>
> 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')
>
> As for encoding the chain identifier, the simplest method is to give
> "network" the "bytes" type, but defining a "UUID" message type is also
> possible. In either case bitcoin mainnet would be the default, so the
> extra 12 bytes (vs: "main" or "test") would only be an issue for
> alt-chains or colored coins.
>
This is essentially name spacing. As registries grow namespaces become
more important. In bitcoin's quest for decentrality there's also the
question of who maintains the registry.
Some out of band algo/hash could work so long as there was a one to one
relationship between the described object and the UUID. In this case the
gensis block may not uniquely identify a coin.
The normal way to namespace a registry on the internet is to allow it to be
a URI. In this case an http style uri has the added bonus side effect that
it can be dereferencable and both human and machine readable. So yes
something like org.bitcoin.* is good, just simply growing things to http
style uris is cleaner, imho
>
> Kind regards,
> Mark Friedenbach
>
>
> ------------------------------------------------------------------------------
> 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
>
[-- Attachment #2: Type: text/html, Size: 4923 bytes --]
next prev parent reply other threads:[~2013-05-22 10:28 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
2013-05-21 4:04 ` Luke-Jr
2013-05-22 10:27 ` Melvin Carvalho [this message]
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=CAKaEYh+eYEApCnbLPZ12RW1XO41epTR4R_nqxM9c3GFHPDEQig@mail.gmail.com \
--to=melvincarvalho@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mark@monetize$(echo .)io \
/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