Talk:Base58Check encoding

From Rosetta Code

prepend leading zeros when the hash digest number has leading ones[edit]

Am I reading the   reference algorithm   (the Base58Check encoding at the bitcoin wiki webpage) correctly in regarding to leading ones (1's) in the (decimal version) hash digest?

In particular, if there are (say) three leading ones in the hash digest, the output string should have three leading zeros.

All of the programming entries so far (except for the REXX version 3 entry) do not address this part of the   reference algorithm   (as shown in the pseudo-code)   at   the Bitcoin's Base58Check page.   -- Gerard Schildberger (talk) 10:23, 17 November 2017 (UTC)

Code examples are NOT Base58Check.[edit]

They are more normal Base58 examples. Base58Check INCLUDES setting a version byte BEFORE anything else, double-SHA256-ing the concatenated hex string and putting the first 4 bytes of the result behind the hex string, then convert the whole thing to Base58.

For example:
Let the input be following hex: 000102030405060708090a0b0c0d0e0f
Put a version byte before it, for example 80. You get 80000102030405060708090a0b0c0d0e0f
Now do a SHA256. You get 4d00ec9820c958f2d198ccc75f6682f7876228eea3ca3bd68c851302438151cb
Now do another SHA256 of the previous SHA256 result. You get 5ffc3b4fca2a220cc9c19c41dfd7248af608f50b188efcbbfa2ae3df96643ad0
Now take the first 4 bytes from this and append them to the hex with the version byte as following: 80000102030405060708090a0b0c0d0e0f5ffc3b4f
This will now be converted to Base58: 8sWmykwPRCRjGtuBczJSJTysdzuaW

This is the whole Base58Check process. It actually works with any hex of any length.
In case of Bitcoin, those hex strings are 32 bytes for private keys and 20 bytes for addresses (not public keys). Also, version bytes are 80 for private keys and 00 for P2PKH addresses (05 for P2SH and SegWit nested in P2SH). Every leading 00 must be denoted with an 1 in the Base58 string.
There can also be more then one version byte. Extended keys in Bitcoin (HD wallets) use 4 version bytes. -- Stl1988 (talk) 07:28, 11 December 2018 (UTC)

As I see it there are three tasks on rosettacode: this one, Bitcoin/address_validation, and Bitcoin/public_point_to_address with the last one doing (almost) what you suggest. This one corresponds to the third option on (say) [[1]] and should not be using sha256, or inserting a version byte. Either that or we should not have three quite-so-similar tasks. I agree that leading zeroes/"1"s are not properly handled by most entries though. Pete Lomax (talk) 11:05, 11 December 2018 (UTC)
If this should only show the Base58 encoding, it should be called Base58, not Base58Check, because there's a difference between these two. Base58 is just the encoding while Base58Check is the process I described above.
It would be awesome to have a code that enables you to manually enter the version byte and doing the whole Base58Check for any hex string. We already have something doing this on [[2]], but it doesn't allow you to manually enter a version byte. -- Stl1988 (talk) 14:16, 11 December 2018 (UTC)