Why base-58 instead of standard base-64 encoding?
Don't want 0OIl characters that look the same in some fonts and
could be used to create visually identical looking account numbers.
A string with non-alphanumeric characters is not as easily accepted as an account number.
E-mail usually won't line-break if there's no punctuation to break at.
Mark H's answer is correct, but I think there is a more fundamental point: addresses are directly intended for human consumption. Transaction hashes (as well as public keys, block hashes, raw scripts, raw transactions, ...) are not. They are sometimes visualized, but this is primarily for debugging purposes. And hexadecimal is a very natural choice for ...
Just like in regular bitcoin addresses (or anything base 58 encoded), the version bytes don't get encoded by themselves. As described in the Serialization format section, there is 78 byte payload that gets versioned and checksumed before then being encoded into base 58:
4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: ...
No, 58^34 is greater than 2^160: http://www.wolframalpha.com/input/?i=2*160+%3E+58*34
Note, that the address also contains a checksum and a network id not carrying additional information. That's why the numbers are not equal.
I usually use the following analogy to oversimplify things: The secret key is how far you walk along a known curve starting from a known point and the public point is where on the curve you wind up when you finish. If you repeat the same walk, you will always wind up at the same place. The operation is irreversible because the curve is complex, you can only ...
When you use that site, you are encoding the hex as a hex string, not of the actual bytes that they should be. The base58 encoding for addresses operates on the bytes themselves which are represented in the hex string. However that website is just encoding the hex string (which, as bytes, is double the length and is entirely other data).
Because P2SH addresses are too short to provide typically desirable levels of security security level we expect from Bitcoin, against certain attacks. On top of that, they use bech32 encoding rather than base58, which means they're slightly longer for the same amount of data, but are case insensitive instead.
For any kind of "multi party" address (...
They should use those:
Or, you can use the CashAddrJS library to convert between them (Here are the browser JS).
Unfortunately there's no RPC command to convert addresses. Sorry!
Your output is correct given the input that you used.
However, If you are expecting to get an output address of 39YteymR86cG7V3Kijg8Gm2ST1r4nTeM1b, it looks like your input is incorrect. It's missing the first byte and the last 4 bytes (encoded as hex):
Your Input: --56379c7bcd6b41188854e74169f844e8676cf8b8--------
Proper Input: ...
The last 4 bytes of the WIF format is a checksum. The details can be seen here: https://en.bitcoin.it/wiki/Wallet_import_format
That's approximately 5 characters of Base58 that are essentially redundant. This is so that errors in the WIF encoded private key can be detected easily. I believe some wallets will simply ignore the checksum if it's not correct.
You're performing a SHA256 on an ASCII string, not on the actual number. That ASCII string is actually the hexadecimal representation of the actual number.
This is a little code snippet that uses a hex2bin function to turn the hexadecimal representation (from your question) into an actual number before performing the sha256 on it.
The bitcoin protocol doesn't really support the concept of a transaction sender.
All you can come up with is an address owned by someone who previously controlled the transaction's outputs, which however might not actually be the sender (e.g. for e-wallets) and who may not actually intend to receive anything there in the first place.
Take some time to see ...
Can someone explain what it is and why it's called Base58Check encoding?
Because of the name the function in the original Bitcoin codebase had.
The "Base58" refers to the fact that it is a base 58 format (it uses 58 different characters to encode the data), and the "Check" refers to the fact that a checksum is added to the encoded data.
Are addresses ...
Can someone explain what it is and why it's called Base58Check encoding?
There are two parts to the name "Base58Check". The first part is "Base58". This is fairly self explanatory, the encoding uses Base 58. This means that there are 58 digits which are represented by 58 characters. One digit is a number between 0 and 57, just like how in the decimal system ...
SHA256 hashes are encoded in plain binary in bitcoin protocol and in block storage (32-bytes in little-endian byte order when treated as integers, which makes them effectively "base256"). The textual hex encoding is merely used for displaying and inputting hashes into the software. Hex is a widely used and understood format for representing arrays of bytes. ...
Individual address private keys begin with 5,L or K. What you're calling root private keys are actually called extended private keys and they begin with ?prv where ? is either x,z,y,Y,Z. You can see examples of those here. So that's how you tell the difference.
Native segwit addresses are not encoded using base58, but using a different encoding system called bech32. The details can be found in BIP 173. For the segwit v1+ addresses that will be used for Taproot, see the amended bech32m encoding in BIP 350.
In short, the addresses consist of:
A human readable part, which is bc for Bitcoin mainnet segwit addresses.
Yes there can be multiple leading '1' characters, and each '1' represents one leading zero byte. This leads to a shorter address because normally each base58 character represents slightly less than 6 bits of information, but a leading zero byte contains exactly 8 bits of information.
For example the shortest address you can have is ...
This answer is probably too late for the OP, but it might clear things up for whoever ends up with the same question later. So here it goes:
I'm assuming you (as I did until a moment ago) have the misconception that the private key is also a pair of (x, y) coordinates in the elliptic curve, just as the public key. Well simple answer, it is not. The private ...
The reason is historical.
The 'version' byte was originally really just a version number. Satoshi probably intended to introduce more types of standard scripts to addresses. There were comments in the code about upgrading an address from one version to a new one even.
In that vision, to not restrict the options for future versions, I chose to make the ...
A picture is worth a 1000 words. See Figure 6 from Chapter 4 of the Bitcoin Book. The last 4 bytes are used as a checksum for error checking. The version prefix is different for Bitcoin altcoin forks. See the 3rd column of this Table for versions used by various altcoins.
If the public key were correct (see Mark's answer), the code is not complete (lacks signature) and contains a hash of an ASCII hexdigest which is not correct.
I'd like to contribute with this implementation of bitcoin address from public key.
It covers the case of both uncompressed and compressed bitcoin addresses (just changing compress_pubkey boolean value)...
A Bitcoin address is a series of bits (on its simpler form is just a public key).
In order to make it human "readable" it is converted to a series of letters.
Base64 is a well known previous algorithm for doing this, but it was decided that characters as O, I, 1, l, +, / could lead to confusion (they are visually similar to others or aren't letters), so 6 ...
Have added my own implementation, complete with a fuzz tester to ensure that it works properly. (The CodecMapping parameter is provided so that you can change the alphabet string as I've had to do from time to time)