Pieter Wuille [ARCHIVE] on Nostr: 📅 Original date posted:2011-07-07 🗒️ Summary of this message: Bitcoin is ...
📅 Original date posted:2011-07-07
🗒️ Summary of this message: Bitcoin is standardizing version bytes for different applications, including network, data class, and version, to prevent collisions and confusion.
📝 Original message:Hello everyone,
after a discussion on IRC, we decided to try to standardize the version bytes
used by bitcoin for several applications.
There are 3 components that seem meaningful:
* network? (realnet, testnet, alternate chains?)
* data class? (address, private key, master key, ...?)
* version? (real version, per data class defined)
There is no technical reason why different network and different data classes
would need separate version bytes, but i think it is a good thing to keep
them from colliding. People will mix them up, and when things are well
defined, a nice warning message could help a lot ("Oops it seems you entered
a private key instead of an address!").
So, first of all, there is already one actually used alternate chain, namely
namecoin, using version byte 52 for addresses. For this reason, i'd like to
reserve bit 16 in the version byte for "alternate chain". When bit 16 is set,
everything is up to the network itself, and no further semantics are defined.
When bit 16 isn't set:
Then remains the rest of the network. The problem is that testnet already uses
version 111, which is not a single bit. We can use a trick though, namely
choosing bit 1 for testnet, and if bit 1 is set, XOR the rest of the version
number with 111. Otherwise, we could reset testnet (not actually reset, just
change its addresses a bit), and simply state odd=testnet, even=realnet.
That leaves use with 6 more bits to play with, namely 128,64,32 and 8,4,2.
As 128 is already used for private keys, let's use (128,64,32) for data classes,
and (8,4,2) for versions.
So, in full:
* Bits 128/64/32 define data class
** 0 = address
** 32,64,96,160,192 = reserved for future use
** 128 = private key
** 224 = extended data class, another "data class" byte follows
* Bit 16 defines "private"
** 0 = bitcoin
** 16 = alternate chain
* Bits 8/4/2 define version number
** 0 = only thing used for now
** 2,4,6,8,10,12 = reserved for future use
** 14 = extended version, another version byte follows
* Bit 1 defines testnet
** 0 = realnet
** 1 = testnet (possibly using XOR 111, if not reset)
This whole discussion started when Stefan wanted to define a format for master keys from which
to derive deterministic wallet keys, i suggest using data class 192 for that, leaving the
lower numbers for more basic data, like public keys.
Any comments?
--
Pieter
Published at
2023-06-07 02:03:36Event JSON
{
"id": "f4de055d9636aa41593dc76fd0e1090cfcada631a6d00ebd833f5d3d90711c4a",
"pubkey": "5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6",
"created_at": 1686103416,
"kind": 1,
"tags": [
[
"e",
"3a6afd5ff34641f5be9f2e62336683df2e1248a1aa2cdee551b6833c651c6625",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2011-07-07\n🗒️ Summary of this message: Bitcoin is standardizing version bytes for different applications, including network, data class, and version, to prevent collisions and confusion.\n📝 Original message:Hello everyone,\n\nafter a discussion on IRC, we decided to try to standardize the version bytes\nused by bitcoin for several applications.\n\nThere are 3 components that seem meaningful:\n* network? (realnet, testnet, alternate chains?)\n* data class? (address, private key, master key, ...?)\n* version? (real version, per data class defined)\n\nThere is no technical reason why different network and different data classes\nwould need separate version bytes, but i think it is a good thing to keep\nthem from colliding. People will mix them up, and when things are well\ndefined, a nice warning message could help a lot (\"Oops it seems you entered\na private key instead of an address!\").\n\nSo, first of all, there is already one actually used alternate chain, namely\nnamecoin, using version byte 52 for addresses. For this reason, i'd like to\nreserve bit 16 in the version byte for \"alternate chain\". When bit 16 is set,\neverything is up to the network itself, and no further semantics are defined.\n\nWhen bit 16 isn't set:\n\nThen remains the rest of the network. The problem is that testnet already uses\nversion 111, which is not a single bit. We can use a trick though, namely\nchoosing bit 1 for testnet, and if bit 1 is set, XOR the rest of the version\nnumber with 111. Otherwise, we could reset testnet (not actually reset, just\nchange its addresses a bit), and simply state odd=testnet, even=realnet.\n\nThat leaves use with 6 more bits to play with, namely 128,64,32 and 8,4,2.\nAs 128 is already used for private keys, let's use (128,64,32) for data classes,\nand (8,4,2) for versions.\n\nSo, in full:\n* Bits 128/64/32 define data class\n** 0 = address\n** 32,64,96,160,192 = reserved for future use\n** 128 = private key\n** 224 = extended data class, another \"data class\" byte follows\n* Bit 16 defines \"private\"\n** 0 = bitcoin\n** 16 = alternate chain\n* Bits 8/4/2 define version number\n** 0 = only thing used for now\n** 2,4,6,8,10,12 = reserved for future use\n** 14 = extended version, another version byte follows\n* Bit 1 defines testnet\n** 0 = realnet\n** 1 = testnet (possibly using XOR 111, if not reset)\n\nThis whole discussion started when Stefan wanted to define a format for master keys from which\nto derive deterministic wallet keys, i suggest using data class 192 for that, leaving the\nlower numbers for more basic data, like public keys.\n\nAny comments?\n\n-- \nPieter",
"sig": "65fe4b67d863edcd42761ff4e83c1c8a79f87febe7e94d55eb061dfa89656408ff54a45f6958f234f5787f8b8c2b0940fb39fd5ff22d3b8378b5eefe658395c1"
}