在比特幣 0.3.6 中添加 OP_NOP 程式碼是硬分叉還是軟分叉？
我正在對歷史共識變化進行更深入的研究，似乎大多數人認為添加 OP_NOP 程式碼是一個硬分叉。這是他們添加的差異：https ://github.com/bitcoin/bitcoin/commit/a75560d828464c3f1138f52cf247e956fc8f937d#
然而，前段時間 gmax 向我提到它實際上是一個軟分叉，因為舊客戶端忽略了未知的操作碼。仔細閱讀程式碼後，我明白為什麼會出現這種情況，但我可以使用一些輸入來獲得具有卓越 C++ 技能的人的共識。
當腳本解釋器遇到未知的操作碼（
default:switch 語句中的情況）時，它會返回false. 這會中止驗證並認為交易無效。在 0.3.6 之前、0.3.6 和今天仍然如此。因此，可能已經創建了某些交易，而 0.3.6 之前的客戶端認為無效，而 0.3.6 之後的客戶端認為有效 - 向後不兼容的共識更改或硬分叉。然而，據我們所知，從來沒有探勘過（甚至創建過）這樣的交易，所以雖然這是一個向後不兼容的變化，但如果沒有這樣的交易，這種不兼容實際上是無法觀察到的。
在您連結到的程式碼差異中沒有任何建議表明舊客戶端在腳本執行中忽略了未知的操作碼，並將它們有效地視為 OP_NOP。這並不能保證他們當然沒有查看所有舊客戶端的程式碼。
但是，將所有未知的操作碼都視為 OP_NOP，然後指定 10 個特定的操作碼是 OP_NOP（OP_NOP1 到 OP_NOP10）並沒有多大意義。此時尚未實現 OP_SUCCESS，因此未知操作碼的唯一兩個選項是將它們視為 OP_NOP 或使腳本失敗。從腳本失敗到被視為 OP_NOP 是對共識規則的放寬（而不是限制），因此將是一個硬分叉。
（當然，在 2010 年還沒有發明軟分叉和硬分叉這兩個術語，因此“硬分叉”協議並不是一個有意識的決定！）