<p>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.</p>

<p>For example the shortest address you can have is 1111111111111111111114oLvT2 (representing 160-bit hash of 0000000000000000000000000000000000000000). It has 21 leading "1" characters representing exactly 21 leading zero bytes (the hash prepended by another 00).</p>

CC BY-SA 4.0
2018-09-11T15:27:10.583Z
No, there are shorter addresses. See this answer: https://bitcoin.stackexchange.com/a/36948
MCCCS
CC BY-SA 3.0
2014-03-11T21:13:21.527Z
2014-03-11T21:13:21.527Z
uminatsu
<p>The wiki entry on <a href="https://en.bitcoin.it/wiki/Address" rel="nofollow">Address</a> says:</p>

<blockquote>
  <p>Some Bitcoin addresses can be shorter than 34 characters (as few as 27 in theory) and still be valid. [...] These shorter addresses are valid simply because they stand for numbers that happen to start with zeroes, and when the zeroes are omitted, the encoded address gets shorter.</p>
</blockquote>

<p>Alright, but according to <a href="https://en.bitcoin.it/wiki/File%3aPubKeyToAddr.png" rel="nofollow">this diagram</a>, a main-network address is:</p>

<pre><code>Base58Check(00 ++ RIPEMD160(SHA256(04 ++ pubkeyX ++ pubkeyY)) ++ checksum)
</code></pre>

<p>Next we look at the entry for <a href="https://en.bitcoin.it/wiki/Base58Check_encoding" rel="nofollow">Base58Check</a> and we see step 4 is:</p>

<blockquote>
  <p>4) Treating the results of step 3 - a series of bytes - as a single big-endian bignumber, convert to base-58 using normal mathematical steps (bignumber division) and the base-58 alphabet described below. <strong>The result should be normalized to not have any leading base-58 zeroes</strong> (character '1').</p>
</blockquote>

<p>First strange thing - if it's treated as a single big-endian number, shouldn't prepending the main network byte of <code>00</code> not have any effect? Since that is the most significant byte it'd be like writing <code>00123</code> instead of <code>123</code> in regular notation, no?</p>

<p>Second strange thing - if the result should be normalized to have no leading zeroes, doesn't that mean that the output should never have any <code>1</code>s in it? Step 5 seems contradictory to this</p>

<blockquote>
  <p>5) The leading character '1', which has a value of zero in base58, is reserved for representing an entire leading zero byte, as when it is in a leading position, has no value as a base-58 symbol. There can be one or more leading '1's when necessary to represent one or more leading zero bytes. Count the number of leading zero bytes that were the result of step 3 (for old Bitcoin addresses, there will always be at least one for the version/application byte; for new addresses, there will never be any). Each leading zero byte shall be represented by its own character '1' in the final result.</p>
</blockquote>

<p>It seems step 4 would have stripped out any possible leading bytes. However, in the case that it didn't, and for some reason it didn't with the prepended <code>00</code> byte, shouldn't an address have multiple leading 1s, e.g. <code>11175tWpb...</code> instead of simply being shorter, e.g. <code>175tWpb...</code>?</p>

<p>EDIT: Ok, it seems that what it is saying is that given payload <code>X</code>, <code>base58(X)</code> is normalized to remove the zeroes, and then you prepend a <code>1</code> for each leading byte of <code>X</code>, not <code>base58(X)</code>. It still raises the question of why addresses are shorter instead of having multiple <code>1</code>s. Is it that the <code>RIPEMD160(SHA256(04 ++ pubkeyX ++ pubkeyY))</code> happens never to have too many leading <code>0</code>s (which would be prepended as <code>1</code>s) while <code>base58(RIPEMD160(SHA256(04 ++ pubkeyX ++ pubkeyY)))</code> does (and they are cut out of the final result)?</p>

<address><algorithms><address-generation><base58check><base58>
Why can addresses be shorter than 34 bytes?
Claudiu
# Why can addresses be shorter than 34 bytes?

(Asked by: username_0 on 2014-03-11)

The wiki entry on [Address](https://en.bitcoin.it/wiki/Address) says:

> Some Bitcoin addresses can be shorter than 34 characters (as few as 27 in theory) and still be valid. [...] These shorter addresses are valid simply because they stand for numbers that happen to start with zeroes, and when the zeroes are omitted, the encoded address gets shorter.

Alright, but according to [this diagram](https://en.bitcoin.it/wiki/File%3aPubKeyToAddr.png), a main-network address is:

```
Base58Check(00 ++ RIPEMD160(SHA256(04 ++ pubkeyX ++ pubkeyY)) ++ checksum)

```

Next we look at the entry for [Base58Check](https://en.bitcoin.it/wiki/Base58Check_encoding) and we see step 4 is:

> 4) Treating the results of step 3 - a series of bytes - as a single big-endian bignumber, convert to base-58 using normal mathematical steps (bignumber division) and the base-58 alphabet described below. **The result should be normalized to not have any leading base-58 zeroes** (character '1').

First strange thing - if it's treated as a single big-endian number, shouldn't prepending the main network byte of `00` not have any effect? Since that is the most significant byte it'd be like writing `00123` instead of `123` in regular notation, no?

Second strange thing - if the result should be normalized to have no leading zeroes, doesn't that mean that the output should never have any `1`s in it? Step 5 seems contradictory to this

> 5) The leading character '1', which has a value of zero in base58, is reserved for representing an entire leading zero byte, as when it is in a leading position, has no value as a base-58 symbol. There can be one or more leading '1's when necessary to represent one or more leading zero bytes. Count the number of leading zero bytes that were the result of step 3 (for old Bitcoin addresses, there will always be at least one for the version/application byte; for new addresses, there will never be any). Each leading zero byte shall be represented by its own character '1' in the final result.

It seems step 4 would have stripped out any possible leading bytes. However, in the case that it didn't, and for some reason it didn't with the prepended `00` byte, shouldn't an address have multiple leading 1s, e.g. `11175tWpb...` instead of simply being shorter, e.g. `175tWpb...`?

EDIT: Ok, it seems that what it is saying is that given payload `X`, `base58(X)` is normalized to remove the zeroes, and then you prepend a `1` for each leading byte of `X`, not `base58(X)`. It still raises the question of why addresses are shorter instead of having multiple `1`s. Is it that the `RIPEMD160(SHA256(04 ++ pubkeyX ++ pubkeyY))` happens never to have too many leading `0`s (which would be prepended as `1`s) while `base58(RIPEMD160(SHA256(04 ++ pubkeyX ++ pubkeyY)))` does (and they are cut out of the final result)?

**Tags:** address, algorithms, address-generation, base58check, base58


---

## 1 answers

### Answer by username_1 on 2014-03-11. Score: 2 | Accepted answer

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 1111111111111111111114oLvT2 (representing 160-bit hash of 0000000000000000000000000000000000000000). It has 21 leading "1" characters representing exactly 21 leading zero bytes (the hash prepended by another 00).

> **Comments:**
> **username_2**: No, there are shorter addresses. See this answer: https://bitcoin.stackexchange.com/a/36948  

---

