Mark Friedenbach [ARCHIVE] on Nostr: š
Original date posted:2013-05-20 š Original message:At the developer ...
š
Original date posted:2013-05-20
š Original message: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
Published at
2023-06-07 15:02:09Event JSON
{
"id": "65d7fc8c2d9771448c98d18b8f329b70be1fef46e5e6a0df85eddf1210d5775f",
"pubkey": "1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069",
"created_at": 1686150129,
"kind": 1,
"tags": [
[
"e",
"f48f714526d322379c9590ee7300f610f029d3880329fd3820bde032fc049d84",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "š
Original date posted:2013-05-20\nš Original message:At the developer round-table it was asked if the payment protocol would \nalt-chains, and Gavin noted that it has a UTF-8 encoded string \nidentifying the network (\"main\" or \"test\"). As someone with two \nproposals in the works which also require chain/coin identification (one \nfor merged mining, one for colored coins), I am opinionated on this. I \nbelieve that we need a standard mechanism for identifying chains, and \none which avoids the trap of maintaining a standard registry of \nstring-to-chain mappings.\n\nAny chain can be uniquely identified by its genesis block, 122 random \nbits is more than sufficient for uniquely tagging chains/colored assets, \nand the low-order 16-bytes of the block's hash are effectively random. \nWith these facts in mind, I propose that we identify chains by UUID.\n\nSo as to remain reasonably compliant with RFC 4122, I recommend that we \nuse Version 4 (random) UUIDs, with the random bits extracted from the \ndouble-SHA256 hash of the genesis block of the chain. (For colored \ncoins, the colored coin definition transaction would be used instead, \nbut I will address that in a separate proposal and will say just one \nthing about it: adopting this method for identifying chains/coins will \ngreatly assist in adopting the payment protocol to colored coins.)\n\nThe following Python code illustrates how to construct the chain \nidentifier from the serialized genesis block:\n\n from hashlib import sha256\n from uuid import UUID\n def chain_uuid(serialized_genesis_block):\n h = sha256(serialized_genesis_block).digest()\n h = sha256(h).digest()\n h = h[:16]\n h = ''.join([\n h[:6],\n chr(0x40 | ord(h[6]) \u0026 0x0f),\n h[7],\n chr(0x80 | ord(h[8]) \u0026 0x3f),\n h[9:]\n ])\n return UUID(bytes=h)\n\nAnd some example chain identifiers:\n\n mainnet: UUID('6fe28c0a-b6f1-4372-81a6-a246ae63f74f')\n testnet3: UUID('43497fd7-f826-4571-88f4-a30fd9cec3ae')\n namecoin: UUID('70c7a9f0-a2fb-4d48-a635-a70d5b157c80')\n\nAs for encoding the chain identifier, the simplest method is to give \n\"network\" the \"bytes\" type, but defining a \"UUID\" message type is also \npossible. In either case bitcoin mainnet would be the default, so the \nextra 12 bytes (vs: \"main\" or \"test\") would only be an issue for \nalt-chains or colored coins.\n\nKind regards,\nMark Friedenbach",
"sig": "aa4aee55d23d816c85378947e0ac8b68c5f0bb202531de6dd041647fccdf4117965708219bfea55e1bdbba89335f5b6c51d9b80e447e1636fb127853aa6d6ead"
}