與 BIP 16 (P2SH) 相關的標準規則
我可以在BIP0016 wiki中閱讀 P2SH 規範
僅當序列化腳本（也稱為redeemScript）本身是其他標準交易類型之一時，贖回這些按腳本付費的交易才被視為標準交易。
在中繼交易或考慮將它們包含在新塊中時驗證這些外點的規則如下：
如果 scriptSig 中存在“推送數據”操作以外的任何操作，則驗證失敗。正常驗證完成：從簽名和{序列化腳本}創建初始堆棧，併計算腳本的雜湊，如果與輸出點中的雜湊不匹配，驗證將立即失敗。{serialized script} 從初始堆棧中彈出，並使用彈出的堆棧和反序列化腳本作為 scriptPubKey 再次驗證事務。在中繼交易或考慮將它們包含在新塊中時驗證這些外點的規則如下：
如果 scriptSig 中存在“推送數據”操作以外的任何操作，則驗證失敗。正常驗證完成：從簽名和{序列化腳本}創建初始堆棧，併計算腳本的雜湊，如果與輸出點中的雜湊不匹配，驗證將立即失敗。{serialized script} 從初始堆棧中彈出，並使用彈出的堆棧和反序列化腳本作為 scriptPubKey 再次驗證事務。…
- OP_CHECKSIG 和 OP_CHECKSIGVERIFY 算作 1 個簽名操作，無論它們是否被評估。
- 緊接在 OP_1 到 OP_16 之前的 OP_CHECKMULTISIG 和 OP_CHECKMULTISIGVERIFY 被計為 1 到 16 個簽名操作，無論它們是否被評估。
- 所有其他 OP_CHECKMULTISIG 和 OP_CHECKMULTISIGVERIFY 都算作 20 次簽名操作。
但在安東諾普洛斯的書中我能讀到
在比特幣核心客戶端 0.9.2 版之前，支付到腳本雜湊被限制為標準類型的比特幣交易腳本，通過 isStandard() 函式。這意味著支出交易中呈現的兌換腳本只能是標準類型之一：P2PK、P2PKH 或多重簽名性質，不包括 RETURN 和 P2SH 本身。從比特幣核心客戶端 0.9.2 版開始，P2SH 交易可以包含任何有效的腳本，這使得 P2SH 標準更加靈活，並允許對許多新穎和復雜的交易類型進行試驗。
現在，我使用的是 0.19.0，我可以創建自定義腳本並在我的 regtest 環境中依賴它。問題是：BIP0016 會過時嗎？如果是，我在哪裡可以看到哪個 BIP 已過時？
通常，BIP 中不指定對策略規則的更改。無論如何，它們取決於個人客戶。
BIP16 並沒有過時，儘管它對比特幣核心標準規則的描述現在已經過時了。然而，自 2012 年啟動以來，它的共識規則（即區塊中的有效內容，而不是作為單個交易轉發的內容）沒有被修改——其他任何東西都將是硬分叉。
就 Bitcoin Core 的政策而言，在 0.10.0（2014 年）版本中，放寬了 P2SH 支出的標準，允許任何腳本使用多達 15 個簽名檢查。後來對標准進行了幾次更改（包括每個受腳本影響的軟分叉（CLTV、CSV、Segwit）都伴隨著相應的支出標準），但都不是那麼重要。
今天（比特幣核心 v0.19.0）P2SH 支出的標準規則包括：
- 最大 scriptSig 大小為 1650 字節，包括redeemScript（未在測試網上強制執行）
- 腳本中最多 15 個簽名檢查（未在測試網上強制執行）
- 沒有用於未來升級的操作碼 (NOP3-NOP10) [不鼓勵升級 nops 規則]
- 沒有非 DER 編碼簽名或混合公鑰 [嚴格規則]
- 沒有在範圍上半部分具有 s 值的簽名 [low-s 規則]
- OP_CHECKMULTISIG(VERIFY) 彈出的附加參數必須完全是空字節數組（由 OP_0 推送）[nulldummy rule]
- 所有推送都必須使用最小尺寸編碼（OP_i 而不是直接推送可用，不需要時沒有 OP_PUSHDATAi），整數不能有不必要的零填充 [minimaldata 規則]
- 執行必須以堆棧上的一個非零元素結束 [cleanstack 規則]
- 失敗的 Checksig 操作必須傳遞一個空簽名 [nullfail rule]
- 不能使用 OP_CODESEPARATOR（即使在未執行的分支中）。
- 經過驗證的簽名不能出現在 scriptPubKey 中（它們必須來自 scriptSig）[const scriptcode rule]
- 在交易級別：沒有高於 2 的 tx 版本，並且整個 tx 不能大於 400000 個權重單位（如果不存在 segwit 輸入，則為 100000 個字節）。