3

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

4

Because P2SH addresses are too short to provide typically desirable levels of security security level 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.

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.
1
  • 1
    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 May 8 at 17:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.