<p>Because Base58 initial <code>1</code>s carry 8 bits of data, but P2SH addresses cannot be represented with a string with initial <code>1</code>s so it starts with <code>3</code> which, like all other cases &amp; characters, encodes 5.86 bits of data. Since the same number of digits encodes fewer bytes, more digits is needed for P2SH.</p>
<p>The P2PKH network byte is 0x00 and the rest is the hash and the checksum. If the hash also starts with 0 digits, P2PKH address will exploit initial 1's efficiency, while P2SH starts with 0x05 so following digits, even if 1's, are not initial 1's and they will not be subjected to the efficiency shortcut I described above.</p>
<p><em>Update</em>:</p>
<p>The Base58Check algorithms is as below:</p>
<p>The serialized data is &quot;network byte&quot; + &quot;20 byte hash&quot; + &quot;4 byte checksum&quot;</p>
<p>The checksum doesn't change the address length at all. Network byte and the hash do.</p>
<p>The serialized data is encoded in the following way:</p>
<pre><code>- Count initial 0x00s and discard them from the serialized data
</code></pre>
<p>For example for mainnet P2PKH addresses (these have network byte = 0x00) if the 20-byte hash starts with 0x<code>00000a...</code>, then there are 3 initial zeros. For other addresses, such as mainnet P2SH (network byte: 0x05), the hash doesn't need to be considered and the number of initial zeros is zero.</p>
<pre><code>- Base-convert the rest
</code></pre>
<p>the standard mathematical operation which can be calculated by long-division. The naive method to calculate this is to represent the binary byte array as a BigNumber and to consider the sequence of remainders.</p>
<hr />
<p>An octal digit corresponds to 3 binary digits because log_2 (8) = 3. Likewise, a Base58 digit corresponds to log_2 (58) = 5.86 binary digits (a little less than exactly 6 digits, for Base64). This is a result of base-conversion.</p>
<p>Nevertheless, if there are initial 0s, when we consume them, we're subtracting 8 bits from bytes-to-be-read-and-serialized instead of 5.86. This is a result of Satoshi's decision to allow shorter addresses at the cost of a higher variance of address lengths (25-34 characters)</p>
<p>The first byte is the network byte. When it's nonzero (for P2SH, it always is!) then there are no initial zeros and the result is 100% derived from base conversion without the initial-zeros shortcut. Just like a six-digit binary number always has 2 decimal digits, all P2SH mainnet addresses have 34 characters.</p>
<p>NOTE: 7-digit binary numbers can have 2 or 3 digits in decimal. Variability by one digit is also possible in address encoding depending on the network byte. This is not the case with mainnet P2SH, it always has 34 bytes. I know this, because both <code>5*256^24</code> and <code>6*256^24 - 1</code> in Base58 have 34 digits. And P2PKH varies by more than one digit because as Pieter Wuille commented, the serialized data of P2SH in binary has a fixed number of digits while that of P2PKH can have many initial zeros (and how those are consumed can be compared to omitting them).</p>

CC BY-SA 4.0
2021-10-02T19:19:23.397Z
In a way, it is no more surprising than the fact that a random number between 0 and 1 million may have 1 through 7 digits, but a random number between 2 and 3 million will always have 7.
Pieter Wuille
CC BY-SA 4.0
2021-10-02T16:33:58.460Z
2021-10-27T11:22:25.487Z
2021-10-27T11:22:25.487Z
MCCCS
<p>Why base58 of P2SH invoice address seems to be never smaller than 34
characters; unlike base58 of P2PKH invoice address, in which 33 characters
is very common?</p>
<p><a href="https://en.bitcoin.it/wiki/Invoice_address" rel="nofollow noreferrer">Bitcoin wiki tells</a> (format and emphasis mine):</p>
<blockquote>
<p>Some Bitcoin invoice addresses can be shorter than 34 characters (as few<br />
as 26) and still be valid. <strong>A significant percentage of Bitcoin invoice<br />
addresses are only 33 characters</strong>, and some invoices may be even shorter.<br />
Technically, every Bitcoin invoice stands for a number. These shorter<br />
invoices are valid simply because they stand for numbers that happen to<br />
start with zeroes, and when the zeroes are omitted, the encoded invoice<br />
address gets shorter.</p>
</blockquote>
<p>But in base58 of P2PKH invoice address, length 33 is a lot more frequent
than in base58 of P2SH. Why does that happen?</p>

<address><p2sh><p2pkh><base58><bitcoin-wiki>
Why P2SH seems to be never smaller than 34 characters, unlike P2PKH?
Mercedes
# Why P2SH seems to be never smaller than 34 characters, unlike P2PKH?

(Asked by: username_0 on 2021-10-02)

Why base58 of P2SH invoice address seems to be never smaller than 34
characters; unlike base58 of P2PKH invoice address, in which 33 characters
is very common?

[Bitcoin wiki tells](https://en.bitcoin.it/wiki/Invoice_address) (format and emphasis mine):

> Some Bitcoin invoice addresses can be shorter than 34 characters (as few  
> as 26) and still be valid. **A significant percentage of Bitcoin invoice  
> addresses are only 33 characters**, and some invoices may be even shorter.  
> Technically, every Bitcoin invoice stands for a number. These shorter  
> invoices are valid simply because they stand for numbers that happen to  
> start with zeroes, and when the zeroes are omitted, the encoded invoice  
> address gets shorter.

But in base58 of P2PKH invoice address, length 33 is a lot more frequent
than in base58 of P2SH. Why does that happen?

**Tags:** address, p2sh, p2pkh, base58, bitcoin-wiki


---

## 1 answers

### Answer by username_1 on 2021-10-02. Score: 5 | Accepted answer

Because Base58 initial `1`s carry 8 bits of data, but P2SH addresses cannot be represented with a string with initial `1`s so it starts with `3` which, like all other cases & characters, encodes 5.86 bits of data. Since the same number of digits encodes fewer bytes, more digits is needed for P2SH.

The P2PKH network byte is 0x00 and the rest is the hash and the checksum. If the hash also starts with 0 digits, P2PKH address will exploit initial 1's efficiency, while P2SH starts with 0x05 so following digits, even if 1's, are not initial 1's and they will not be subjected to the efficiency shortcut I described above.

*Update*:

The Base58Check algorithms is as below:

The serialized data is "network byte" + "20 byte hash" + "4 byte checksum"

The checksum doesn't change the address length at all. Network byte and the hash do.

The serialized data is encoded in the following way:

```
- Count initial 0x00s and discard them from the serialized data

```

For example for mainnet P2PKH addresses (these have network byte = 0x00) if the 20-byte hash starts with 0x`00000a...`, then there are 3 initial zeros. For other addresses, such as mainnet P2SH (network byte: 0x05), the hash doesn't need to be considered and the number of initial zeros is zero.

```
- Base-convert the rest

```

the standard mathematical operation which can be calculated by long-division. The naive method to calculate this is to represent the binary byte array as a BigNumber and to consider the sequence of remainders.

---

An octal digit corresponds to 3 binary digits because log\_2 (8) = 3. Likewise, a Base58 digit corresponds to log\_2 (58) = 5.86 binary digits (a little less than exactly 6 digits, for Base64). This is a result of base-conversion.

Nevertheless, if there are initial 0s, when we consume them, we're subtracting 8 bits from bytes-to-be-read-and-serialized instead of 5.86. This is a result of Satoshi's decision to allow shorter addresses at the cost of a higher variance of address lengths (25-34 characters)

The first byte is the network byte. When it's nonzero (for P2SH, it always is!) then there are no initial zeros and the result is 100% derived from base conversion without the initial-zeros shortcut. Just like a six-digit binary number always has 2 decimal digits, all P2SH mainnet addresses have 34 characters.

NOTE: 7-digit binary numbers can have 2 or 3 digits in decimal. Variability by one digit is also possible in address encoding depending on the network byte. This is not the case with mainnet P2SH, it always has 34 bytes. I know this, because both `5*256^24` and `6*256^24 - 1` in Base58 have 34 digits. And P2PKH varies by more than one digit because as username_2 username_2 commented, the serialized data of P2SH in binary has a fixed number of digits while that of P2PKH can have many initial zeros (and how those are consumed can be compared to omitting them).

> **Comments:**
> **username_2**: In a way, it is no more surprising than the fact that a random number between 0 and 1 million may have 1 through 7 digits, but a random number between 2 and 3 million will always have 7.  

---

