如果有人仍然可以使用 P2SH 使用非標準交易，那麼不轉發非標準交易有什麼用？
似乎非標準交易通常不會被中繼，因為有人擔心這可能會破壞網路，或者可能會使未來的升級更加困難。
但是任何人都可以使用 P2SH 使用這些非標準交易（並讓它們被轉發！）。那麼這個對非 P2SH 腳本的限制有什麼好處呢？
正如您所說，這裡有兩個不同的問題：
- 有一些腳本可能會對網路造成危害。
- 有一些腳本可能會使未來的升級更加困難。
對於危害網路的情況，非標準的交易檢查是中本聰在P2SH出現之前就已經實現的，所以不可能那麼容易被規避。這使開發人員有時間更好地分析腳本語言並解決剩餘操作碼的問題（例如，查看這樣的案例，其中可能創建需要很長時間才能驗證的事務）。
然而，即使腳本語言非常安全，每個腳本也必須由每個完整節點儲存，直到它作為未使用事務輸出 (UTXO) 數據庫的一部分被使用。由於 scriptPubKeys 限制為 10,000 字節，這意味著攻擊者可以為他創建的每個輸出添加多達 10KB 的 UTXO 集，可能會快速添加足夠的數據以降低性能，從而使探勘的陳舊塊（孤立塊）的速率增加，這將減少礦工的利潤，並鼓勵他們進一步集中化以彌補損失的收入。
那會很糟糕。令人高興的是，有一個簡單的解決方案：如果我們使用 P2SH 或 segwit P2WSH，我們只能在輸出被使用時看到完整的腳本——當我們可以從 UTXO 集中刪除輸出時。由於 P2SH 將腳本限制為 520 字節，因此這在某種程度上稍遜一籌，但 P2WSH 修復了該問題並恢復了早期的 10,000 字節限制。這就是我們今天需要復雜腳本使用 P2SH 的安全原因。
對於升級案例，有一些我們不希望人們使用的操作碼。最值得注意的是，這些操作碼可能會在未來重新定義，例如過去用於軟分叉的 OP_NOPx 操作碼（OP_NOP1 變為 OP_CHECKLOCKTIMEVERIFY，OP_NOP2 變為 OP_CHECKSEQUENCEVERIFY）。最近，Bitcoin Core 0.16.1 已停止在非隔離見證中中繼 OP_CODESEPARATOR，以準備另一個潛在的軟分叉，這將減少一些揮之不去的昂貴驗證問題。
在這些情況下，標準交易同時禁止 scriptPubKey 和redeemScript (P2SH) 版本（以及適用時的segwit P2WSH 版本），因此在這種情況下不可能輕鬆繞過。