<ul>
<li>The encoding is bech32 not base58, which is slightly longer but vastly easier to type due to a lack of capital letters, and the inclusion of error correction rather than error detection.</li>
<li>SegWit scripts use SHA256 not RIPEMD160 for the hash function, which is longer and stronger.</li>
</ul>

CC BY-SA 4.0
2021-05-08T17:01:43.483Z
Two super tiny nits: the bech32 checksum is 30 bits, while the base58 one is 32 bits long, so the presence of the checksum isn't a reason why the result is longer (it's of course still a relevant difference between the two). P2PKH uses SHA256+RIPEMD160, not just RIPEMD160.
Pieter Wuille
CC BY-SA 4.0
2021-05-08T16:20:19.513Z
2021-05-08T16:20:19.513Z
Claris
<p>Because P2SH addresses are too short to provide the typically desirable level of security 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.</p>
<p>For any kind of &quot;multi party&quot; address (that is, an address constructed by multiple distinct and distrusting participants that each have their own key, such as multisig), a particular collision attack exists that has runtime <em>O(2<sup>bits/2</sup>)</em>, where bits is the number of bits of entropy in the address.</p>
<p>P2PKH, P2WPKH, and P2SH addresses have 160-bit hashes in their addresses. For P2PKH and P2WPKH this is fine, as it only supports single-party construction. However, as P2SH supports multisig and other multi-party constructions, it means an <em>~2<sup>80</sup></em> attack is possible(*). Bitcoin typically has a <em>2<sup>128</sup></em> security target for attacks, so this is insufficient. That doesn't mean such a collision attack is practical - it's just far weaker than what the rest of the system provides, and as computing performance increases it may become feasible for well-funded parties.</p>
<p>To address this, P2WSH introduced a multi-party-capable address that contains a 256-bit hash, so it has <em>~2<sup>128</sup></em> collision security.</p>
<p>In the upcoming Taproot upgrade, a new P2TR address type is introduced. It has the same length as P2WSH addresses, and also contains ~256 bits of entropy. Due to the nature of Taproot, which merges P2PKH and P2SH style spending into one, this means even single-party addresses are 256 bits in it.</p>
<p>For details of the attack, see <a href="https://bitcoin.stackexchange.com/a/54847/208">https://bitcoin.stackexchange.com/a/54847/208</a>.</p>
<p>(*) There are ways to avoid the collision attack problem, even with short hashes. They significantly complicate address construction and spending however. So the choice to provide a 256-bit script hash mechanism is really just to make sure multi-party address construction isn't needlessly complicated.</p>

CC BY-SA 4.0
2021-05-08T16:29:01.387Z
2023-09-19T21:34:34.513Z
2023-09-19T21:34:34.513Z
Pieter Wuille
<p>One would, perhaps naively, assume that both addresses are hashes of scripts and therefore ought to be the same size.</p>

<segregated-witness><p2sh><bech32-address><base58><p2wsh>
Why are P2WSH addresses larger than P2SH addresses?
Bertram Lund
# Why are P2WSH addresses larger than P2SH addresses?

(Asked by: username_0 on 2021-05-08)

One would, perhaps naively, assume that both addresses are hashes of scripts and therefore ought to be the same size.

**Tags:** segregated-witness, p2sh, bech32-address, base58, p2wsh


---

## 2 answers

### Answer by username_2 on 2021-05-08. Score: 7 | Accepted answer

Because P2SH addresses are too short to provide the typically desirable level of security 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 (that is, an address constructed by multiple distinct and distrusting participants that each have their own key, such as multisig), a particular collision attack exists that has runtime *O(2bits/2)*, where bits is the number of bits of entropy in the address.

P2PKH, P2WPKH, and P2SH addresses have 160-bit hashes in their addresses. For P2PKH and P2WPKH this is fine, as it only supports single-party construction. However, as P2SH supports multisig and other multi-party constructions, it means an *~280* attack is possible(\*). Bitcoin typically has a *2128* security target for attacks, so this is insufficient. That doesn't mean such a collision attack is practical - it's just far weaker than what the rest of the system provides, and as computing performance increases it may become feasible for well-funded parties.

To address this, P2WSH introduced a multi-party-capable address that contains a 256-bit hash, so it has *~2128* collision security.

In the upcoming Taproot upgrade, a new P2TR address type is introduced. It has the same length as P2WSH addresses, and also contains ~256 bits of entropy. Due to the nature of Taproot, which merges P2PKH and P2SH style spending into one, this means even single-party addresses are 256 bits in it.

For details of the attack, see <https://bitcoin.stackexchange.com/a/54847/208>.

(\*) There are ways to avoid the collision attack problem, even with short hashes. They significantly complicate address construction and spending however. So the choice to provide a 256-bit script hash mechanism is really just to make sure multi-party address construction isn't needlessly complicated.


---

### Answer by username_1 on 2021-05-08. Score: 3

* The encoding is bech32 not base58, which is slightly longer but vastly easier to type due to a lack of capital letters, and the inclusion of error correction rather than error detection.
* SegWit scripts use SHA256 not RIPEMD160 for the hash function, which is longer and stronger.

> **Comments:**
> **username_2**: Two super tiny nits: the bech32 checksum is 30 bits, while the base58 one is 32 bits long, so the presence of the checksum isn't a reason why the result is longer (it's of course still a relevant difference between the two). P2PKH uses SHA256+RIPEMD160, not just RIPEMD160.  

---

