My notes on bitcoin addresses

Bitcoin addresses are usually represented in a human friendly readable format called Base58Check. You can think of it as a modified, easier to read version of Base 64. The payload (typically in hex format) will have a prefix appended (depending on the type of information being encoded). The prefix + payload concatenation is run through SHA256 hashing function twice which produces a 32 byte value. The first 4 bytes of this hash is used as the checksum and is added to the result: prefix + payload + checksum. Finally, this is encoded in Base 58 for the resulting address. It looks like this:

1thMirt546nngXqyPEz532S8fLwbozud8

Here is a diagram showcasing this:

Both private and public keys can be expressed in Base58Check. For example, private keys can be denoted in hex, WIF (Wallet Import Format) or WIF-Compressed (I will explain the difference later). From the hex payload, the required prefix is appended, and resulting checksum is calculated. The result is encoded in Base 58 which will produce the required format. A slight distinction here is that the WIF-Compressed format will have its hex payload appended with a suffix of 01 prior to Base58Check encoding.

Base58Check encoding examples

With public keys, we will have the elliptic curve point (x,y) and is denoted as:

04 + x + y

This format is called “uncompressed public key”. There is a way to compress this by using only the x coordinate and a prefix representing y being even or odd. Recall, that given x, the following elliptic curve formula can be used to solved for y:

y² mod p = (x³ + 7) mod p

If y can deduced from x, the resulting “compressed public key” can be represented as 02 + x or 03 + x. 02 prefix is added when y is even, otherwise 03 prefix is used for when y is odd. This allows us to substantially reduce the size of transactions on the blockchain resulting in huge storage savings over time. New wallets will typically derive the bitcoin address from compressed public keys.

However; this can add some complexity as now from the same private key, we can have an uncompressed and compressed format of the public key that can be derived from it. Therefore, 2 possible bitcoin addresses can be generated as a result. If we are to use this private key in another wallet application, how can we determine whether to use the compressed or uncompressed format of the public key and therefore the correct bitcoin address?? This leads us to how private keys are formatted for import to other wallets.

WIF (Wallet Import Format)

In WIF format, the private key in hexadecimal is encoded with Base58Check using prefix 128 or 0x80. The result is the human friendly readable format that starts with 5. With WIF, the uncompressed public key will be used with format 04 + x + y. After computing the SHA256 and RIPEMD160 of this resulting format, it is then encoded with Base58Check using the prefix 0 or 0x00. The result is a bitcoin address starting with 1.

WIF Compressed

In WIF-Compressed, the hex private key with suffix 01 is encoded to Base58Check using the same prefix 128 or 0x80. This will produce the Base58Check encoded private key starting with K or L. The resulting public key is “compressed” with 02 + x or 03 + x (depending on y being even or odd). After computing the SHA256 and RIPEMD160 of this resulting format, it is then encoded with Base58Check using the prefix 0 or 0x00. The result is a bitcoin address starting with 1.

Private key format representations

On my next bitcoin notes topic, I will go thru the different types of wallets.