Why are P2WSH addresses larger than P2SH addresses?

Question

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

Answer 1

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(2^bits/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 ~2⁸⁰ attack is possible(*). Bitcoin typically has a 2¹²⁸ 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 ~2¹²⁸ 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 2

• 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.