二次散列問題：為什麼不直接創建新的 OP 程式碼“CHECKSIG2”來修復？
為什麼“我們”不能
OP_CHECKSIG用軟分叉解決二次散列問題？使用軟分叉更新
NO_OPx，OP_CHECKSIG2其中OP_CHECKSIG2不進行二次散列（可能對每個輸入使用所有數據的單個 tx 散列？）。為 P2SH 等新流程創建新的交易類型，並在足夠廣泛的網路採用之後，軟分叉以OP_CHECKSIGBIP 66 的工作方式使任何舊交易無效？或者我的假設是否存在根本問題，即“可能對每個輸入使用所有數據的單個 tx 雜湊”是可能的？
**注意：**截至 2020 年，此答案已過時，因為 BIP143 / SegWit 已使用多年，可以解決此問題。
您可以通過這種方式修復它，並且有人正在這樣做。
散列整個交易的問題在於，為了創建交易散列，您必須知道簽名。但是，為了創建簽名，您需要知道交易雜湊。要完成這項工作，您需要避免對 scriptSig 進行散列處理。這就是比特幣所做的，但它的實現方式阻止你將雜湊用於一個輸出並將其用於另一個輸出。
BIP143（隔離見證的一部分）提出了一個數據（大部分）散列一次的系統。
定義了一種新的交易摘要算法，但僅適用於版本 0 見證程序中的 sigops：
雙SHA256的序列化：
- nVersion of the transaction (4-byte little endian)
- hashPrevouts（32 字節雜湊）
- hashSequence（32 字節散列）
- outpoint（32 字節雜湊 + 4 字節小端）
- 輸入的 scriptCode（序列化為 CTxOuts 中的腳本）
- 此輸入所花費的輸出值（8 字節小端序）
- nSequence 輸入（4 字節小端）
- hashOutputs（32 字節雜湊）
- n 交易的鎖定時間（4 字節 little endian）
- 簽名的 sighash 類型（4 字節 little endian）
這將針對每個輸入執行。除了 scriptCode 之外，它的每一部分都是固定長度的，但是沒有辦法讓一個 scriptCode 被多個輸入散列。有三個基於可變長度資訊的輸入，hashPrevouts、hashSequence 和 hashOutputs，但那裡的惡作劇可能性有限。所有計算它們的方法要麼散列一個輸入/輸出，要麼由整個事務共享，要麼全為零。
驗證非常大的 BIP143 交易將花費線性時間，並且由簽名驗證主導。但是，目前無法進行 BIP143 交易，因為礦工尚未接受隔離見證。
我認為你不能像那樣對 CHECKSIG 進行軟分叉。腳本看起來像這樣
sig pubkey DUP HASH keyhash EQUALVERIFY NOPX/CHECKSIG2
新客戶端將驗證這一點並最終得到一個有效的 tx。老客戶在 NOPX 什麼都不做，最終得到一個無效的 tx。