Bitcoin transaction construction bridges theoretical protocol knowledge with practical implementation. A transaction selects UTXOs to spend, builds outputs with locking scripts, creates signatures for each input, and serializes everything in the exact format nodes expect. The process requires understanding sighash generation, Script behavior, and correct fee and change handling.

Each transaction input references a previous output by txid and index. Outputs specify amounts in satoshis and locking scripts. The difference between total inputs and total outputs is the fee. To sign an input, a modified version of the transaction is serialized, its sighash is computed, and the private key signs it. The resulting signature and public key form the ScriptSig. Once every input is signed, the raw transaction can be broadcast to the network.

Bare multisig uses OP_CHECKMULTISIG to require m-of-n signatures. Due to an early off-by-one bug, OP_CHECKMULTISIG consumes an extra stack element, requiring an initial OP_0 in the ScriptSig. Bare multisig is functional but inefficient: all public keys appear on-chain, making scriptPubKeys large, expensive, and difficult to encode as addresses. These limitations motivated the introduction of pay-to-script-hash.

P2SH hides complex scripts behind a 20-byte HASH160. The scriptPubKey is fixed: OP_HASH160 <20-byte hash> OP_EQUAL. The underlying redeem script—containing multisig, timelocks, or other conditions—is only revealed and executed when spending. The sender only sees the hash, while the receiver manages the redeem script privately. This design reduces on-chain size, improves privacy, and enables complex contracts without burdening senders.

To spend a P2SH output, the ScriptSig must include the necessary unlocking data plus the redeem script itself. Validation occurs in two steps:

When generating signatures for a P2SH input, the sighash process uses the redeem script in place of the scriptPubKey. Each signer must possess the full redeem script to generate valid signatures. P2SH addresses use version byte 0x05 on mainnet (“3…” addresses) and 0xC4 on testnet (“2…” addresses).

Losing a redeem script means losing funds: spending requires both the private keys and the redeem script itself. Multisig participants must verify that their public keys are correctly included before accepting deposits. P2SH supports advanced constructions like multisig, timelocks, and hashlocks, but errors in script logic can permanently lock funds, so testing on testnet is essential.

P2SH improves privacy by hiding spending conditions until the first spend, but once the redeem script appears on-chain, it becomes permanently visible. Despite this, the benefits of reduced size, backward compatibility, and flexible contract support made P2SH a major milestone, influencing later upgrades such as SegWit and Taproot.