Bytecode Structures of P2WPKH and P2WSH Outputs

Under Segregated Witness rules, locking scripts (scriptPubKeys) are significantly more compact and elegant than their legacy counterparts.

Let's dissect the exact bytecode layouts of the two primary SegWit locking formats: P2WPKH (Pay-to-Witness-Public-Key-Hash) and P2WSH (Pay-to-Witness-Script-Hash).

---

🔑 1. P2WPKH (Pay-to-Witness-Public-Key-Hash)

P2WPKH is the SegWit equivalent of legacy P2PKH, used for standard payments to a single public key.

⚙️ The locking script (scriptPubKey)

OP_0  [20-Byte Public Key Hash]

🔍 Bytecode Breakdown:

• OP_0 (0x00): The first byte defines the Witness Version (currently Version 0).
• Push Data (0x14): The second byte is the hexadecimal instruction to push exactly 20 bytes of data to the stack (0x14 = 20 in decimal).

• Key Hash (20 bytes): The 20-byte RIPEMD160(SHA256(Public Key)) hash.

• Total Output Size: Exactly 22 bytes (down from legacy P2PKH's 25 bytes, saving blockspace on every output transaction!).

---

📝 2. P2WSH (Pay-to-Witness-Script-Hash)

P2WSH is the SegWit equivalent of legacy P2SH, used to lock funds to complex smart contracts, such as multisig agreements or timelocked escrows.

⚙️ The locking script (scriptPubKey)

OP_0  [32-Byte Witness Script Hash]

🔍 Bytecode Breakdown:

• OP_0 (0x00): The Witness Version (Version 0).
• Push Data (0x20): The second byte is the hexadecimal instruction to push exactly 32 bytes of data to the stack (0x20 = 32 in decimal).

• Script Hash (32 bytes): The 32-byte SHA-256 hash of the serialized contract code (known as the witnessScript).

• Total Output Size: Exactly 34 bytes.

---

🛡️ Why P2WSH Upgraded to a 32-Byte Hash (SHA-256)

A critical security difference exists between legacy P2SH and Native SegWit P2WSH:

• Legacy P2SH hashes its redeemScript using RIPEMD-160, yielding a 20-byte (160-bit) hash.
• Native P2WSH hashes its witnessScript using SHA-256, yielding a 32-byte (256-bit) hash.

💥 The Birthday Attack Risk

In cryptography, the Birthday Paradox states that finding a collision (two different scripts that yield the exact same hash) is much easier than reversing a specific hash. * For a 160-bit hash (legacy P2SH), the theoretical effort required to find a script collision is:

$$2^{160/2} = 2^{80} \text{ operations}$$

While $2^{80}$ is currently computationally difficult, highly funded adversaries or supercomputing grids could potentially generate two different smart contracts (one benign, one malicious) that hash to the same 20-byte legacy P2SH address, allowing them to steal locked escrow funds.

• By upgrading P2WSH to use a 32-byte SHA-256 hash, the collision search space increases exponentially:

$$2^{256/2} = 2^{128} \text{ operations}$$

An effort of $2^{128}$ operations is mathematically secure and completely immune to birthday-attack collisions for the foreseeable future, ensuring ultimate security for advanced smart contracts on Bitcoin!