Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)
On 21 May 2013 01:59, Mark Friedenbach m...@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
--
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
Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)
On Wed, May 22, 2013 at 6:27 AM, Melvin Carvalho melvincarva...@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. jgar...@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
Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)
On 22 May 2013 16:07, Jeff Garzik jgar...@exmulti.com wrote: On Wed, May 22, 2013 at 6:27 AM, Melvin Carvalho melvincarva...@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. jgar...@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
Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)
On Wed, May 22, 2013 at 10:12 AM, Melvin Carvalho melvincarva...@gmail.com wrote: On 22 May 2013 16:07, Jeff Garzik jgar...@exmulti.com wrote: On Wed, May 22, 2013 at 6:27 AM, Melvin Carvalho melvincarva...@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. jgar...@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
Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)
On Wednesday, May 22, 2013 2:20:22 PM Jeff Garzik wrote: On Wed, May 22, 2013 at 10:12 AM, Melvin Carvalho melvincarva...@gmail.com wrote: On 22 May 2013 16:07, Jeff Garzik jgar...@exmulti.com wrote: On Wed, May 22, 2013 at 6:27 AM, Melvin Carvalho melvincarva...@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. -- 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
Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)
On Wed, May 22, 2013 at 10:29 AM, Luke-Jr l...@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. jgar...@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
Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)
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/ -- 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
[Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)
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
Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)
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.
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.
jgar...@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
Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)
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 jgar...@exmulti.com 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.
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.
jgar...@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
--
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
