wiki needs an edit regarding initial numbers/characters for addresses.

[Cryddit]

I don't have a key to edit the wiki, but for whoever does, the following page: 

https://en.bitcoin.it/wiki/List_of_address_prefixes

is wrong about what initial bytes bitcoin actually uses in its addresses.

From the source code, we have

0 for base58 '1' (pubkey addresses on mainnet)
5 for base58 '3' (scripthash addresses on mainnet)
128 for base58 '5' (secret keys on mainnet) <--- wiki page says 111
111 for base58 'm' or 'n' (pubkey addresses on testnet)
196 for base58 '2' (scripthash addresses on testnet)
239 for base58 '2' (secret keys on testnet)    <-- wiki page says base58 'c'

[Muhammed Zakir]

From your thread and the wiki, only '238 for base58's leading character is weong. Other all looks fine. If I am wrong, please correct me. I can edit wiki.

   -MZ

[Cryddit]

From your thread and the wiki, only '238 for base58's leading character is weong. Other all looks fine. If I am wrong, please correct me. I can edit wiki.

   -MZ

Secret keys on testnet start with 239 (as the wiki page says) but in base58 form do they really start with 'c'?

[Muhammed Zakir]

Secret keys on testnet start with 239 (as the wiki page says) but in base58 form do they really start with 'c'?

239 is decimal version. I think uncompressed addresses start with 9 and compressed start with c.

   -MZ

[Newar]

Can you link to the relevant parts in the source code, so we can use them as references on the wiki?

[Cryddit]

You need lines 161 to 165 of chainparams.cpp for mainnet, and lines 220 to 224 for testnet.

Here's the mainnet source:

Code:

        base58Prefixes[PUBKEY_ADDRESS] = list_of(0);
        base58Prefixes[SCRIPT_ADDRESS] = list_of(5);
        base58Prefixes[SECRET_KEY] =     list_of(128);
        base58Prefixes[EXT_PUBLIC_KEY] = list_of(0x04)(0x88)(0xB2)(0x1E);
        base58Prefixes[EXT_SECRET_KEY] = list_of(0x04)(0x88)(0xAD)(0xE4);

and here's the testnet source:

Code:

        base58Prefixes[PUBKEY_ADDRESS] = list_of(111);
        base58Prefixes[SCRIPT_ADDRESS] = list_of(196);
        base58Prefixes[SECRET_KEY]     = list_of(239);
        base58Prefixes[EXT_PUBLIC_KEY] = list_of(0x04)(0x35)(0x87)(0xCF);
        base58Prefixes[EXT_SECRET_KEY] = list_of(0x04)(0x35)(0x83)(0x94);

In both blocks, the first line is the pay-to-pubkey prefix byte, the second is the pay-to-script-hash prefix byte, the third is the secret-key prefix byte.  The fourth is a sequence of four bytes that prefixes deterministic-wallet public keys (so called "stealth addresses", as well as special keys that allow someone to accept but not spend payments &c. ) and the fifth is a sequence of four bytes used to prefix the corresponding deterministic-wallet secret keys.

Because the the prefix bytes are attached to a base256 encoding (ie, binary) of known width,  they affect the leading cinquantoctal digit of the corresponding base58 representation of the same number.  That zero is why mainnet pay-to-pubkey txouts always start with 1, the 5 is why mainnet pay-to-script-hash txouts always start with 3, and so on.

Incidentally, the four-byte prefixes correspond to cinquantoctal prefixes 'xpub' and 'xprv' on mainnet and 'tpub' and 'tprv' on testnet.  Somebody with far too much time to invest in encoding transformations figured out what range of numeric values would start with 'xpub' and 'xpriv' etc when converted to base58 from a binary number 4 bytes wider than a key value, then exactly which four bytes to prefix to ensure that the base256 representation always yields a number in that range.

[TheRealSteve]

I looked this over, and have made some changes to that page to - hopefully - clarify things a wee bit.

Specifically:

• added a column for the hex representation
• added references to related pages
• added reference to the aforementioned source code
• swapped the 'leading symbol(s)' and 'use' columns, renaming the latter to 'Example use'*

* I think this makes it more clear that the leading symbol(s) actually depend on the 'use'.  E.g. the prefix '05' is generally only going to consistently yield a leading symbol '3' if the use case is a P2SH address with matching input.

Those with edit privileges: Feel free to correct/modify as you see fit.
Those without: go request edit privileges!   But on this specific topic, feel free to just add a post to this thread.

Note that I'm not entirely certain that all this information is appropriately within the scope of 'List of address prefixes', which to me should mean only addresses - not Base58Check encodings of any other information, such as private keys.  That's a different discussion, though

[tspacepilot]

[snip]

Because the the prefix bytes are attached to a base256 encoding (ie, binary) of known width,  they affect the leading cinquantoctal digit of the corresponding base58 representation of the same number.  That zero is why mainnet pay-to-pubkey txouts always start with 1, the 5 is why mainnet pay-to-script-hash txouts always start with 3, and so on.

[snip]

Ok, I have to admit, I was floored to see the phrase "base256 encoding (ie, binary)".  Googling base256 turned up nothing that stood out to me as explaining how base256 is "ie base2".  In my mind base256 is going to mean 256 unique symbols and I can see that it would be a very compact way to represent very large numbers, a base 256 number which was 4 characters long could represent up to 1.34*10^154 values (right?).

Clearly I'm misunderstanding something completly.  And since I'm really interested in educating myself, I'd love any help here (even if it's just a pointer to some reading I should do).

Thanks!

[Cryddit]

Base256 is 256 values per byte - binary is two values per bit.  Same basic encoding, just interpreted at different unit width.

[tspacepilot]

Base256 is 256 values per byte - binary is two values per bit.  Same basic encoding, just interpreted at different unit width.

Ok, I think I can understand that fairly clearly.

0x00 -- 0xff encodes decimal 0 -- 255.  If I write that down in binary I've got 00000000 -- 11111111.  I can say one byte is a unit and call it base 256 but now my question is this: how is this helpful?  Why not just call a spade a spade, so to speak, and recognize that this is base2?

Thanks again for the education on this matter!

[Cryddit]

Mostly because a byte is the smallest unit you can easily handle and do anything with -- and you can handle bits only in the context of being parts of larger units for the most part.  So I think of encodings in terms of bytes, making it 256.

[tspacepilot]

Mostly because a byte is the smallest unit you can easily handle and do anything with -- and you can handle bits only in the context of being parts of larger units for the most part.  So I think of encodings in terms of bytes, making it 256.

I think I can see how that makes sense in a practical way.  I need to take a closer look at the bitcoin-core code and see if I can learn a little more.  Thanks again, I'll leave off this for now.  Cheers!