Pay To Script Hash Increases Security Of Bitcoin Transaction

The flexibility and security of Bitcoin Transactions are greatly increased by Pay to Script Hash (P2SH), a type of transaction output. P2SH permits money to be transferred to a script hash, also referred to as a redeem script, rather than being locked directly to a Public Key or public key hash. Transactions are more adaptable and user-friendly because to this approach, which abstracts the complexity of the real spending conditions.

History and Purpose of P2SH

Gavin Andresen originally added Pay to Script Hash to the Bitcoin network at Block 173805 on April 1, 2012, after it was specified in BIP 16. Support for it grew swiftly since it addressed a number of issues with earlier transaction types, like Pay-to-Pubkey-Hash (P2PKH) and Pay-to-Pubkey (P2PK), which were the only conventional options available at the time.

Moving the burden of providing the requirements to redeem a transaction from the sender of the funds to the redeemer (receiver) is the main goal of P2SH. The sender would have to include the complete sophisticated script in the transaction’s locking script prior to P2SH if the receiver requested complex spending conditions (such as requesting multiple signatures). Pay to Script Hash made this process easier by letting senders utilize a brief hash of the spending criteria instead of the lengthy, cumbersome script.

How P2SH Works

P2SH functions according to the “commit-and-reveal” principle:

Redeem Script Definition: First, the recipient creates a redemption script that includes the real, frequently intricate spending conditions. A number of requirements, including multiple digital signatures, passwords, or other conditions, may be included in this script. A 2-of-3 multi-signature script is a typical redeem script, for instance.

Address Derivation: The Pay to Script Hash Bitcoin address is then generated using the hashed script, which is the redeem script (more precisely, a RIPEMD-160(SHA-256()) hash).

• In the mainnet, Pay to Script Hash addresses are easily recognised since they always start with the number ‘3’. Unlike P2PKH addresses, which begin with ‘1’ (0x00 prefix), this is because their base58check encoding has a particular version byte prefix (0x05).

Funding Transaction (ScriptPubKey): The transaction output’s locking script (ScriptPubKey), which is encircled by the OP_HASH160 and OP_EQUAL opcodes, only includes the hash of the redeem script when the sender sends bitcoins. “You must provide a redemption script that hashes to this specific value in order to spend these funds,” this script basically says. The locking script currently does not contain the redemption script itself.

Spending Transaction (ScriptSig & Verification): In the unlocking script (ScriptSig) of their spending transaction, the recipient must supply two requirements in order to spend the bitcoins that are locked to a Pay to Script Hash address:

• The public keys (or other data) and digital signatures that the original redeem script requested.
• The redemption narrative in its entirety.

Validating a P2SH transaction

A two-step procedure is followed while validating a Pay to Script Hash transaction:

Step 1: Hash Verification: The ScriptSig’s redemption script is first hashed with OP_HASH160. Next, using OP_EQUAL, this freshly calculated hash is contrasted with the redeem script hash that is stored in the ScriptPubKey. The first criterion is satisfied if the hashes are identical.

Step 2: Redeem Script Execution: With the supplied signatures and data, the redeem script (which was included in the ScriptSig) is reserialized and run as though it were the locking script in the event that the hash verification is successful. This guarantees the fulfilment of its internal spending requirements. For the transaction to be approved, the authenticity of the redeem script and the hash verification are both necessary.

Advantages of Pay to Script Hash

Pay to Script Hash has many advantages over more traditional transaction formats.

Simplification for the Sender:  Complex or lengthy scripts are no longer required in transactions sent by senders. They merely transfer money to a brief, unremarkable Pay to Script Hash address that begins with the letter “3.” This significantly lowers the possibility of human error when transcribing addresses.

Enhanced Security and Flexibility: Pay to Script Hash is essential for implementing sophisticated transaction types that require many approvals to complete, including multi-signature (multisig) addresses. It also makes additional complicated conditions possible, such as escrow contracts and timelocks.

Reduced Transaction Size and Fees for the Sender: In the ScriptPubKey, the sender simply includes the short hash, so the initial transaction size is less. This reduces the sender’s transaction expenses. The recipient bears the financial responsibility because the larger redeem script is only included after the money has been spent.

Improved Privacy: Before the money is actually spent and the redeem script is made public, the specifics of the spending circumstances are concealed by utilizing a hashed script for the address. Therefore, it is impossible for observers to determine if an output is the property of one person or if it needs to be spent by several parties.

Backward Compatibility (Nested SegWit): Although not as comprehensive as Native SegWit (Bech32), Pay to Script Hash can work with SegWit and non-SegWit (P2PKH) addresses. “Nested SegWit” is the term used when a P2SH-formatted wallet is created using private keys. Trezor hardware wallets, for example, support “Legacy SegWit” addresses, which are P2SH compatible.

Computational Efficiency and Smaller UTXO Set: In the UTXO set, P2SH scripts are smaller than full P2MS (Pay-to-Multi-Sig) scripts, which means that nodes need less RAM to keep unspent outputs. This speeds up node validation of transactions.

Auditability and Verification: Transaction validation concerns are neatly separated with P2SH’s two-stage verification method, which first verifies the redeem script’s hash and then checks its requirements.

Limitations of P2SH

P2SH has certain drawbacks in spite of its benefits:

Increased Overall Blockchain Data Size: Even though the sender’s transaction size is decreased, the entire P2SH transaction including the revealed redeem script often occupies a little more space on the blockchain than a direct, simpler script (for example, a 2-of-3 multisig P2SH script is 278 bytes, whereas a direct P2MS script is 253 bytes).

Script Conditions Revealed on Spending: While anonymity is initially improved, unlike more recent methods like Taproot, the whole script conditions are exposed once the money is spent.

Less Common for Single Signatures: For straightforward single-signature transactions, other script types are more frequently utilized because P2SH was initially designed for multisig wallets and more sophisticated scripts.

Usage and Examples

Multiple digital signatures are needed to prove ownership and spend money in multi-signature (multisig) transactions, which are where P2SH is most frequently employed. More complex custom locking scripts, such hash-collision challenges or mathematical puzzles, can also use it.

With over 10.5 million P2SH unspent transaction outputs (UTXOs) and over 31% of the current Bitcoin supply (over 5.8 million BTC) kept in P2SH outputs, P2SH transactions are still commonly used today.

Summary Table