* Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)
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
2013-05-21 4:04 ` Luke-Jr
2013-05-22 10:27 ` Melvin Carvalho
2 siblings, 2 replies; 12+ messages in thread
From: Jeff Garzik @ 2013-05-21 2:45 UTC (permalink / raw)
To: Mark Friedenbach; +Cc: bitcoin-development
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.
> 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.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)
2013-05-21 2:45 ` Jeff Garzik
@ 2013-05-21 3:30 ` Mike Hearn
2013-05-21 4:00 ` Mark Friedenbach
1 sibling, 0 replies; 12+ messages in thread
From: Mike Hearn @ 2013-05-21 3:30 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2328 bytes --]
Bitcoinj already has such chain id's and we use standard Java style reverse
DNS names: org.bitcoin.main, etc. If we want a more global naming system
that seems like a good compromise between uniqueness and readability.
On 20 May 2013 19:45, "Jeff Garzik" <jgarzik@exmulti•com> 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.
>
>
> > 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.
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik@exmulti•com
>
>
> ------------------------------------------------------------------------------
> 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: 3103 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)
2013-05-21 2:45 ` Jeff Garzik
2013-05-21 3:30 ` Mike Hearn
@ 2013-05-21 4:00 ` Mark Friedenbach
1 sibling, 0 replies; 12+ messages in thread
From: Mark Friedenbach @ 2013-05-21 4:00 UTC (permalink / raw)
To: Jeff Garzik; +Cc: bitcoin-development
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?
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)
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 4:04 ` Luke-Jr
2013-05-22 10:27 ` Melvin Carvalho
2 siblings, 0 replies; 12+ messages in thread
From: Luke-Jr @ 2013-05-21 4:04 UTC (permalink / raw)
To: bitcoin-development
Bitcoin currently uses raw hashes extensively as UUIDs; whether the payment
protocol should be influence by that or not, I've not given thought to yet.
Some alt coins may share a blockchain, or even merely the genesis block (two
currently do; despite one of those being a scamcoin, I think the possibility
should not be dismissed). Because of this, requiring a 1:1 mapping between
genesis block and chain or coin seems non-ideal.
On Monday, May 20, 2013 11:59:39 PM Mark Friedenbach 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.
>
> 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
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)
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 4:04 ` Luke-Jr
@ 2013-05-22 10:27 ` Melvin Carvalho
2013-05-22 14:07 ` Jeff Garzik
2 siblings, 1 reply; 12+ messages in thread
From: Melvin Carvalho @ 2013-05-22 10:27 UTC (permalink / raw)
To: Mark Friedenbach; +Cc: Bitcoin Dev
[-- 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 --]
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)
2013-05-22 10:27 ` Melvin Carvalho
@ 2013-05-22 14:07 ` Jeff Garzik
2013-05-22 14:12 ` Melvin Carvalho
0 siblings, 1 reply; 12+ messages in thread
From: Jeff Garzik @ 2013-05-22 14:07 UTC (permalink / raw)
To: Melvin Carvalho; +Cc: Bitcoin Dev
On Wed, May 22, 2013 at 6:27 AM, Melvin Carvalho
<melvincarvalho@gmail•com> wrote:
> 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.
What does this mean? It seems extremely unlikely that two different
genesis blocks will have the same hash.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)
2013-05-22 14:07 ` Jeff Garzik
@ 2013-05-22 14:12 ` Melvin Carvalho
2013-05-22 14:20 ` Jeff Garzik
0 siblings, 1 reply; 12+ messages in thread
From: Melvin Carvalho @ 2013-05-22 14:12 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 591 bytes --]
On 22 May 2013 16:07, Jeff Garzik <jgarzik@exmulti•com> wrote:
> On Wed, May 22, 2013 at 6:27 AM, Melvin Carvalho
> <melvincarvalho@gmail•com> wrote:
> > 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.
>
> What does this mean? It seems extremely unlikely that two different
> genesis blocks will have the same hash.
>
Two coin ecosystems could have the same genesis block
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik@exmulti•com
>
[-- Attachment #2: Type: text/html, Size: 1261 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)
2013-05-22 14:12 ` Melvin Carvalho
@ 2013-05-22 14:20 ` Jeff Garzik
2013-05-22 14:29 ` Luke-Jr
0 siblings, 1 reply; 12+ messages in thread
From: Jeff Garzik @ 2013-05-22 14:20 UTC (permalink / raw)
To: Melvin Carvalho; +Cc: Bitcoin Dev
On Wed, May 22, 2013 at 10:12 AM, Melvin Carvalho
<melvincarvalho@gmail•com> wrote:
> On 22 May 2013 16:07, Jeff Garzik <jgarzik@exmulti•com> wrote:
>>
>> On Wed, May 22, 2013 at 6:27 AM, Melvin Carvalho
>> <melvincarvalho@gmail•com> wrote:
>> > 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.
>>
>> What does this mean? It seems extremely unlikely that two different
>> genesis blocks will have the same hash.
>
>
> Two coin ecosystems could have the same genesis block
That has really, really bad side effects. The whole point of the
bitcoin consensus algorithm is to avoid situations like this.
We don't want to encourage that behavior with code.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)
2013-05-22 14:20 ` Jeff Garzik
@ 2013-05-22 14:29 ` Luke-Jr
2013-05-22 14:55 ` Jeff Garzik
0 siblings, 1 reply; 12+ messages in thread
From: Luke-Jr @ 2013-05-22 14:29 UTC (permalink / raw)
To: bitcoin-development
On Wednesday, May 22, 2013 2:20:22 PM Jeff Garzik wrote:
> On Wed, May 22, 2013 at 10:12 AM, Melvin Carvalho
>
> <melvincarvalho@gmail•com> wrote:
> > On 22 May 2013 16:07, Jeff Garzik <jgarzik@exmulti•com> wrote:
> >> On Wed, May 22, 2013 at 6:27 AM, Melvin Carvalho
> >>
> >> <melvincarvalho@gmail•com> wrote:
> >> > 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.
> >>
> >> What does this mean? It seems extremely unlikely that two different
> >> genesis blocks will have the same hash.
> >
> > Two coin ecosystems could have the same genesis block
>
> That has really, really bad side effects. The whole point of the
> bitcoin consensus algorithm is to avoid situations like this.
>
> We don't want to encourage that behavior with code.
In some cases, multiple currencies can use the same blockchain (not just the
singular genesis block). This use case *is* something we want to encourage -
no reason for people to make an entirely new blockchain if their altcoin fits
within the scope of Bitcoin or another existing altchain.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)
2013-05-22 14:29 ` Luke-Jr
@ 2013-05-22 14:55 ` Jeff Garzik
2013-05-22 15:59 ` Gavin Andresen
0 siblings, 1 reply; 12+ messages in thread
From: Jeff Garzik @ 2013-05-22 14:55 UTC (permalink / raw)
To: Luke-Jr; +Cc: bitcoin-development
On Wed, May 22, 2013 at 10:29 AM, Luke-Jr <luke@dashjr•org> wrote:
> In some cases, multiple currencies can use the same blockchain (not just the
> singular genesis block). This use case *is* something we want to encourage -
> no reason for people to make an entirely new blockchain if their altcoin fits
> within the scope of Bitcoin or another existing altchain.
OK, let me qualify. Layers on top are one thing, but we really do not
want to support cases like the fork that leaves the genesis block
intact, and leaves the subsidy at 50.0 BTC forever.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)
2013-05-22 14:55 ` Jeff Garzik
@ 2013-05-22 15:59 ` Gavin Andresen
0 siblings, 0 replies; 12+ messages in thread
From: Gavin Andresen @ 2013-05-22 15:59 UTC (permalink / raw)
To: Jeff Garzik; +Cc: bitcoin-development
Getting back to the original proposal:
RE: uuid instead of "main" / "test" in the payment protocol:
I vote no.
The payment protocol will become at least 3 BIPs:
1) Protocol messages (current gist, essentially)
2) MIME type
3) bitcoin: URI extension
An alt coin will need its own version of (2) and (3), so when you
click on a foocoin: link a foocoin-specific MIME type is fetched and
foocoin.exe is launched to handle the request.
... or a specific MIME type is fetched and delivered to the
HandlesLotsOfCoins application (... and it knows what MIME type it is
getting, so can Do the Right Thing).
If a payment request is delivered via HTTP or email, it will be
bundled up in an envelope of some sort with the MIME type attached.
So, after further thought, I've changed my mind: which coin would be
encoded in the MIME type. Which chain for that coin would be encoded
in PaymentDetails.network.
--
--
Gavin Andresen
Chief Scientist, Bitcoin Foundation
https://www.bitcoinfoundation.org/
^ permalink raw reply [flat|nested] 12+ messages in thread