為什麼最初保留 OP_RESERVED、OP_RESERVED1 和 OP_RESERVED2？
自比特幣最早公開發布以來，
OP_RESERVED、OP_RESERVED1、 和OP_RESERVED2已分別在0x50(80)、0x89(137) 和0x8a(138) 中定義。為什麼？
所有其他現在禁用的操作碼的預期目的似乎都有很好的記錄，但是我們是否有任何記錄或解釋為什麼將
OP_RESERVED{1,2}操作碼分配在其目前位置？
OP_RESERVED似乎很清楚地允許OP_1(0x51, 81) 到OP_16(0x60, 96) 將每個推送的數字與字節的後半部分 1 對 1 匹配（這樣0x515253很容易讀為OP_1 OP_2 OP_3）。也可以保留它以確保編寫原始合約的使用者不會意外地假設0x50是OP_0(0x00) 或OP_1NEGATE(0x4f, 79)，這可能很容易混淆，因為0x80在腳本編號編碼中基本上是一個負號。（關於為什麼中本聰沒有填寫的任何其他想法OP_RESERVED？）對於
OP_RESERVED1和OP_RESERVED2，推理似乎不那麼明顯。在最舊的送出中，它們列在下面
// bit logic，一組 8 個操作碼，從0x83(131) 開始，一直持續到OP_RESERVED2(0x8a, 138)。這些似乎不屬於任何特別特殊的程式碼點，並且前面或後面的操作碼“組”都不是在任何明顯特殊的程式碼點處開始或結束。
0x89/137 和/138是否有一些不尋常的地方0x8a，中本聰可能已經為這些程式碼點保留了這些程式碼點？是否有其他指令集保留它們（或者保留它們使“比特幣指令集”與該指令集一致）？
自比特幣最早公開發布以來，OP_RESERVED、OP_RESERVED1 和 OP_RESERVED2 已分別定義在 0x50 (80)、0x89 (137) 和 0x8a (138)。
我懷疑它們存在的任何已知原因。顯然，比特幣中的腳本引擎在開發過程中和接下來的一年中經歷了很多變化；所有操作碼的很大一部分被完全重寫，行為
OP_FALSE被反轉，OP_CODESEPERATOR被執行更改有效地刪除，等等。這些更改和刪除有許多殘餘，並且許多操作碼對於它們的處理方式有不明顯的怪癖。值得記住的是，比特幣的原始版本至少部分實現了 > 8 位操作碼，並在第二年被刪除，因此為指示其擴展的字節保留了一些空間。
是否有其他指令集保留它們（或者保留它們使“比特幣指令集”與該指令集一致）？
比特幣腳本的指令集似乎受到了 2000 年代早期一篇描述“安全性”的研究論文的影響，但是這個線上的副本似乎已經完全腐爛了。值得注意的是，運算符的順序是相同的，並且具有匹配的奇怪之處，例如
OP_2OVER和OP_3DUP，但這些也被當時許多其他類似的語言所共享。