See the bitcoin-development list for discussion of this proposal.
Topic: UUID to identify chains (payment protocol and elsewhere) (Read 3654 times)
I support this proposal.
At the developer round-table it was asked if the payment protocol would support 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:
And some example chain identifiers:
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.
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:
Code:
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)
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:
Code:
mainnet: UUID('6fe28c0a-b6f1-4372-81a6-a246ae63f74f')
testnet3: UUID('43497fd7-f826-4571-88f4-a30fd9cec3ae')
namecoin: UUID('70c7a9f0-a2fb-4d48-a635-a70d5b157c80')
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.
Jump to: