Skip to content
twostacktwostacktwostack

Addresses

Bitcoin Addresses are a wallet concern. This is very important to note. The Address itself is never seen on, or broadcast to, the Bitcoin network. Addresses take no part in the consensus mechanism of Bitcoin, and play no part in validating Transactions.

What the network sees is the Locking Script of an Output. For the familiar P2PKH (Pay to Public Key Hash) Output, that Locking Script holds a 20-byte hash of the recipient’s Public Key. The Address is a way of writing that hash down so that one person can hand it to another. The primary function of the Address format is to package the hash in such a way that transcription errors are hard to make, and easy to detect.

Deriving an Address

Section titled “Deriving an Address”

Figure 1 shows how one gets from a Public Key to an Address. The example is a real testnet Address, and the bytes underneath the 25-byte row are its actual contents.

The Public Key is hashed with SHA256 and then RIPEMD160 to give a 20-byte hash value. A version byte is prepended. The double SHA256 of those 21 bytes gives a checksum, of which the first 4 bytes are appended, for 25 bytes in all. Base58 encoding of the 25 bytes gives the Address. Public Key 4-byte checksum 04 x-coordinate y-coordinate RIPEMD160( SHA256( public_key ) ) ver hash_value: 20 bytes SHA256( SHA256( ver + hash ) ) checksum ver hash_value checksum Base58 encode n3aZKucfWmXeXhX13MREQQnqNfbrWiYKtg 04: uncompressed 02 or 03: compressed, x-coordinate only version byte 00 mainnet, 6f testnet first 4 bytes 25 bytes 6f f2014222 … b238fb64 13a5c505
Figure 1: Derivation of a Base58Check-encoded Address

Referring to Figure 1, we notice a few interesting things:

  1. We start from the Public Key, in either its uncompressed (04, followed by both coordinates) or its compressed (02 or 03, followed by the x-coordinate alone) serialisation. The two forms hash to different values, so the same key gives two different Addresses. Wallets today use the compressed form.
  2. The Public Key is hashed with SHA-256, and the result hashed again with RIPEMD-160. This 20-byte result is the Public Key Hash (hash_value), and it is the very same hash that ends up in the Locking Script.
  3. A version byte is put in front of the hash. It tells the wallet which network the Address is meant for, and which kind of Output to build: 00 for a mainnet P2PKH Address, 6f for testnet. This is why mainnet Addresses start with a 1, and testnet Addresses with an m or an n.
  4. The version byte and hash are hashed twice with SHA-256, and the first 4 bytes of the result are appended as a checksum. That gives us 25 bytes in all.
  5. Finally, the 25 bytes are encoded in Base58.

Base58 is Base64 without the characters that are easy to mistake for one another: 0 (zero), O (capital o), I (capital i) and l (lower-case L), as well as + and /. Together with the checksum, this is what makes an Address hard to mistype. A wallet that decodes an Address recomputes the checksum, and a single wrong character makes it fail, with only about a 1 in 4 billion chance of a mistake slipping through.

From an Address back to a Locking Script

Section titled “From an Address back to a Locking Script”

It should be noted that the hashing only goes one way. There is no way to get back the Public Key associated with an Address if we are only given the Address. The Public Key is revealed only later, in the Unlocking Script of the Transaction that spends the coins.

When we pay to an Address, the wallet works through Figure 1 in reverse, as far as it can:

  1. It decodes the Base58 string into 25 bytes.
  2. It recomputes the checksum and refuses the Address if it doesn’t match.
  3. It checks the version byte, and refuses a mainnet Address on testnet, or the other way around.
  4. It unpacks the Public Key Hash, and builds the P2PKH Locking Script of the new Output around it:
OP_DUP OP_HASH160 <hash_value> OP_EQUALVERIFY OP_CHECKSIG

From this point on the Address plays no further part. The network only ever sees the Locking Script. You can read more about this script in Standard Script Templates.

The same format was used for P2SH (Pay to Script Hash) Addresses, with a hash of a script in place of the Public Key Hash, and a version byte of 05 on mainnet (Addresses starting with a 3) or c4 on testnet. Since the Genesis upgrade in 2020, Bitcoin SV no longer accepts new P2SH Outputs, so you are unlikely to need them.

Addresses in our applications

Section titled “Addresses in our applications”

Because Addresses are only a convention between wallets, an application is free to do without them. In the peer-to-peer payments we use today, the payee’s wallet derives a fresh key for every payment and hands its invoice directly to the payer’s wallet. Nobody needs to read an Address off a screen or type one in. Addresses remain the right tool wherever a person has to copy a payment destination by hand, or a QR code is all the two parties share.

Do note that an Address should be used for one payment only. Every payment to the same Address links those payments together in public, for anyone who cares to look.

Both of our libraries take care of the details above. You can see how to create, parse and validate Addresses in DartSV and Bitcoin4J.