Published on: 2011-07-08T09:25:07+00:00
On July 8, 2011, an email exchange between Pieter, Stefan, and John discussed the possibility of resetting testnet addresses or using the XOR hack to differentiate between testnet and realnet addresses. Stefan suggested using the lsb as a flag, but John argued for maintaining backward compatibility. Pieter mentioned that the 111 hack visually distinguishes testnet codes from realnet ones. He also noted that modifying nVersion by less than 5 can keep the first base58 character the same. Additionally, he suggested using +/- 111 instead of XOR 111.Pieter Wuille initiated a discussion on standardizing version bytes used by Bitcoin on July 7, 2011. The three components considered were network, data class, and version. While there is no technical reason for separate version bytes, it helps prevent confusion. Bit 16 in the version byte was proposed for "alternate chain" and if set, the network has its own semantics. For testnet, bit 1 would be used and XORing the rest of the version number with 111 when bit 1 is set. They could also slightly change testnet addresses and designate odd numbers as testnet and even numbers as realnet. This leaves six more bits to use - 128, 64, 32, and 8, 4, 2. The proposal suggests using (128, 64, 32) for data classes and (8, 4, 2) for versions.The discussion started by Pieter Wuille on standardizing version bytes used by Bitcoin for multiple applications. The proposal aimed at establishing a convention before individual definitions arise. The proposal applies to non-alternate chains and is compatible with existing version bytes used for testnet, realnet, addresses, private keys, namecoin, and multicoin. The proposal suggests using specific functions for encoding base58-encoded data structures and addresses. An 'EncodeVersionByte' function would encode the class, nVersion, and fTestNet values into an integer version byte for Base58 encoding.A decision to standardize version bytes used in Bitcoin applications was made during an IRC discussion. The three components considered were network, data class, and version. While there is no technical reason for separate version bytes, it helps prevent collisions. Bit 16 in the version byte was reserved for "alternate chain", allowing the network to define its own semantics when set. Testnet currently uses version 111, and bit 1 can be chosen for testnet. If bit 1 is set, XORing the rest of the version number with 111 would differentiate it from realnet. Alternatively, testnet addresses could be slightly changed and odd numbers designated as testnet and even numbers as realnet. This leaves six more bits to use - 128, 64, 32, and 8, 4, 2. The proposal suggests using (128, 64, 32) for data classes and (8, 4, 2) for versions.
Updated on: 2023-08-01T02:05:57.896338+00:00