Stefan Thomas [ARCHIVE] on Nostr: 📅 Original date posted:2011-07-08 🗒️ Summary of this message: Bitcoin is ...
📅 Original date posted:2011-07-08
🗒️ Summary of this message: Bitcoin is standardizing version bytes for different applications, with reserved bits for network, data class, and version number. Testnet may use XOR hack or reset.
📝 Original message:Hey Pieter,
> Otherwise, we could reset testnet (not actually reset, just
> change its addresses a bit), and simply state odd=testnet, even=realnet.
We could use the XOR hack for now and remove it the next time we reset
testnet. But I do think the 111 is baggage we want to get rid of. Using
the lsb as a simple flag is much cleaner.
Cheers,
Stefan
On 7/7/2011 1:15 PM, Pieter Wuille wrote:
> 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?
>
Published at
2023-06-07 02:03:43Event JSON
{
"id": "b1d8853fffdc0092905a45922002f48b4e840f9e2bfd3f69cd7678b0739c63a1",
"pubkey": "49f07bd32c0108a2903a0fa59f904ed312e0ea427d3269eb5fa910eb4a9e22c4",
"created_at": 1686103423,
"kind": 1,
"tags": [
[
"e",
"3a6afd5ff34641f5be9f2e62336683df2e1248a1aa2cdee551b6833c651c6625",
"",
"root"
],
[
"e",
"616e851f83dd705c5f034d7eb42e6cc36a9196236c159144382555147703064f",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2011-07-08\n🗒️ Summary of this message: Bitcoin is standardizing version bytes for different applications, with reserved bits for network, data class, and version number. Testnet may use XOR hack or reset.\n📝 Original message:Hey Pieter,\n\n\u003e Otherwise, we could reset testnet (not actually reset, just\n\u003e change its addresses a bit), and simply state odd=testnet, even=realnet.\n\nWe could use the XOR hack for now and remove it the next time we reset \ntestnet. But I do think the 111 is baggage we want to get rid of. Using \nthe lsb as a simple flag is much cleaner.\n\nCheers,\n\nStefan\n\n\nOn 7/7/2011 1:15 PM, Pieter Wuille wrote:\n\u003e Hello everyone,\n\u003e\n\u003e after a discussion on IRC, we decided to try to standardize the version bytes\n\u003e used by bitcoin for several applications.\n\u003e\n\u003e There are 3 components that seem meaningful:\n\u003e * network? (realnet, testnet, alternate chains?)\n\u003e * data class? (address, private key, master key, ...?)\n\u003e * version? (real version, per data class defined)\n\u003e\n\u003e There is no technical reason why different network and different data classes\n\u003e would need separate version bytes, but i think it is a good thing to keep\n\u003e them from colliding. People will mix them up, and when things are well\n\u003e defined, a nice warning message could help a lot (\"Oops it seems you entered\n\u003e a private key instead of an address!\").\n\u003e\n\u003e So, first of all, there is already one actually used alternate chain, namely\n\u003e namecoin, using version byte 52 for addresses. For this reason, i'd like to\n\u003e reserve bit 16 in the version byte for \"alternate chain\". When bit 16 is set,\n\u003e everything is up to the network itself, and no further semantics are defined.\n\u003e\n\u003e When bit 16 isn't set:\n\u003e\n\u003e Then remains the rest of the network. The problem is that testnet already uses\n\u003e version 111, which is not a single bit. We can use a trick though, namely\n\u003e choosing bit 1 for testnet, and if bit 1 is set, XOR the rest of the version\n\u003e number with 111. Otherwise, we could reset testnet (not actually reset, just\n\u003e change its addresses a bit), and simply state odd=testnet, even=realnet.\n\u003e\n\u003e That leaves use with 6 more bits to play with, namely 128,64,32 and 8,4,2.\n\u003e As 128 is already used for private keys, let's use (128,64,32) for data classes,\n\u003e and (8,4,2) for versions.\n\u003e\n\u003e So, in full:\n\u003e * Bits 128/64/32 define data class\n\u003e ** 0 = address\n\u003e ** 32,64,96,160,192 = reserved for future use\n\u003e ** 128 = private key\n\u003e ** 224 = extended data class, another \"data class\" byte follows\n\u003e * Bit 16 defines \"private\"\n\u003e ** 0 = bitcoin\n\u003e ** 16 = alternate chain\n\u003e * Bits 8/4/2 define version number\n\u003e ** 0 = only thing used for now\n\u003e ** 2,4,6,8,10,12 = reserved for future use\n\u003e ** 14 = extended version, another version byte follows\n\u003e * Bit 1 defines testnet\n\u003e ** 0 = realnet\n\u003e ** 1 = testnet (possibly using XOR 111, if not reset)\n\u003e\n\u003e This whole discussion started when Stefan wanted to define a format for master keys from which\n\u003e to derive deterministic wallet keys, i suggest using data class 192 for that, leaving the\n\u003e lower numbers for more basic data, like public keys.\n\u003e\n\u003e Any comments?\n\u003e",
"sig": "51bdd3d04f4c79158eb2ea37f48066605f83a64c86b36a32de886a39d7c5a168750d31a59dc8831f74e624a0a7d32f28164f6f162786f94435625a24b0586e4e"
}