簡介
比特幣改進提議目的
pay-to-script-hash目的是將提供條件的責任從資金髮送者轉移到接收方。
好處是允許傳送者發起無論多複雜的交易，使用足夠短的20位元組固定長度的散列來掃描QR碼或輕鬆地複製和貼上。
詳細說明
定義了一個包含在採礦區塊中的新標準交易類型：
OP_HASH160[20-byte-hash-value]OP_EQUAL
[20-byte-hash-value]應為推20位元組到堆疊操作碼（0x14），後跟20個位元組。
這個新的交易類型被標準腳本代碼贖回：
signatures...{serializedscript}
如果序列化腳本（也稱為redeemScript）本身就是其他標準交易類型之一，那么兌換這些pay-to-scriptoutpoints的交易只能被視為標準。
傳播交易或將其納入新區塊時對這些outpoints進行驗證的規則如下：
如果scriptSig(解鎖腳本)中存在除“pushdata”以外的任何操作，驗證失敗。
正常驗證完成：從簽名和{序列化腳本}創建初始堆疊，並且計算腳本的哈希值，如果它與outpoint的哈希不匹配，則驗證失敗。
{serializedscript}從初始堆疊彈出，並使用彈出的堆疊和反序列化腳本作為scriptPubKey再次驗證交易。
這些新規則只應在使用時間戳=>1333238400（2012年4月1日）的區塊中驗證交易時套用。
在區塊鏈中早於1333238400個的交易，套用這些新的驗證規則會失敗。。較舊的交易必須根據舊規則進行驗證。（有關詳細信息，請參閱向後兼容性部分）。
例如，scriptPubKey和相應的scriptSig用於單簽名所需的交易：
scriptSig:[signature]{[pubkey]OP_CHECKSIG}scriptPubKey:OP_HASH160[20-byte-hashof{[pubkey]OP_CHECKSIG}]OP_EQUAL
{序列化腳本}中的簽名操作將有助於每個塊允許的最大數量（20,000），如下所示：
OP_CHECKSIG和OP_CHECKSIGVERIFY計數為1簽名操作，不管它們是否被評估。
OP_CHECKMULTISIG和OP_CHECKMULTISIGVERIFY之前的OP_1到OP_16將被計入1到16簽名操作，不管它們是否被評估。
所有其他OP_CHECKMULTISIG和OP_CHECKMULTISIGVERIFY都被計為20個簽名操作。
舉例：
+3簽名操作：{2[pubkey1][pubkey2][pubkey3]3OP_CHECKMULTISIG}
+22簽名操作：{OP_CHECKSIGOP_IFOP_CHECKSIGVERIFYOP_ELSEOP_CHECKMULTISIGVERIFYOP_ENDIF}
理論依據
這個BIP替代了BIP12，它提出了一個新的腳本操作碼（“OP_EVAL”）來完成此BIP中的所有操作。
這個BIP的動機（和BIP13，pay-to-script-hash地址類型）有些爭議；有人覺得這是不必要的，複雜/多重簽名的交易類型應該是通過簡單地向傳送人提供完整的{序列化腳本}來支持的。此BIP已經將改動做到最小，用以將資金髮送到base58編碼的20位元組比特幣地址，從而允許商家和交易所及其他軟體開始支持多重簽名交易。
識別scriptPubKey的一個“特殊”形式，並在檢測到時執行額外的驗證是醜陋的。然而，一致認為，替代方案要么越來越複雜，要么以危險的方式擴大表達語言的力量。
簽名操作計數規則旨在通過靜態掃描{序列化腳本}來簡單快速地實現。比特幣對每個區塊施加最大數的簽名操作，以防止對礦工的拒絕服務攻擊。如果沒有限制，流氓礦工可能會廣播一個需要數十萬個ECDSA簽名操作進行驗證的區塊，並且可能能夠開始計算下一個塊，而網路的其餘部分工作來驗證當前的這個區塊。
對舊的實現有一次確認的攻擊，但在實踐中是昂貴和困難的。攻擊是：
攻擊者創建一個pay-to-script-hash交易，這對舊軟體是有效的，但對新實現無效，並使用它傳送一些比特幣。
攻擊者還創建一個pay-to-script標準交易，並支付運行舊軟體的受害者。
攻擊者運算一個包含這兩個交易的塊。
如果受害者接受1次確認付款，則攻擊者獲勝，因為當網路的其餘部分覆蓋攻擊者的無效塊時，兩個交易將被無效。
攻擊是昂貴的，因為它要求攻擊者創建一個他們知道\將被網路的其它節點確認無效的區塊。這是困難的，因為創建區塊是的代價是非常高的，用戶不應該接受高價值交易的一次確認交易。
向後兼容
這些交易對於舊的實現是非標準的，它們（通常）不會傳播它們或將它們包含在區塊中。
舊的實現將驗證{serializescript}的哈希值在驗證由完全支持此BIP的軟體創建的區塊時匹配，但不會進行其他驗證。
為了避免區塊鏈被通過惡意pay-to-script交易分割需要仔細處理一種情況：
一個pay-to-script-hash交易對新客戶/礦工無效，但對舊客戶/礦工有效。
為了正常升級並確保不會發生持久的區塊鏈分裂，超過50%的礦工必須支持對新交易類型的全面驗證，並且必須同時從舊的驗證規則切換到新的規則。
為了判斷是否有超過50%的散列能力支持此BIP，礦工們被要求升級他們的軟體，並將字元串“/P2SH/”輸入到他們創建的區塊的coinbase交易中。
2012年2月1日，檢查區塊鏈，以確定在過去7天支持pay-to-script-hash的區塊數。如果550個或更多的coinbase交易中包含“/P2SH/”，那么在2012年2月15日00:00:00之後的所有具有時間戳的區塊將具有完全驗證的pay-to-script-hash交易。一周內創建約1,000個區塊;因此，550應該是支持新功能的網路的大約占比55%。
如果大多數散列算力不支持新的驗證規則，那么推出將被推遲（或者如果明確表示絕大多數將永遠不會實現）。
腳本大小
序列化腳本大小限制在520位元組
作為向後兼容性的要求的結果，序列化腳本本身受到與任何其他PUSHDATA操作相同的規則，包括大於520位元組的數據可能被推送到堆疊的規則。因此，如果所引用的兌換腳本長度大於520位元組，則不可能花費P2SH輸出。例如，當OP_CHECKMULTISIG操作碼本身可以接受多達20個pubkey時，使用33位元組壓縮的公鑰，只能花費最多需要15個pubkey的P2SH輸出來兌換：3個位元組+15個pubkeys*34個位元組/pubkey=513位元組。
