交易中的版本
原始交易十六進制：
02000000000101fff8d9d39105eeec162fb45bd2a3e796b255866469a2cc7de93e438f3722c1490000000000fdffffff02801a0600000000001600145b497cfd64324fb0c4f7317472ca591cd7eb3bbfe093040000000000160014b1348ec3acd422b7c84f97f8757a0a5c3db9e32d02473044022020c3a9d7d06429008de82f13de672aac7886c5d6557a7c330bcb8cbc20b8cf4f02203890042ed8bf331e92f07df5d2a7bf5d8ade12cbb216f14493a98d0a188c4918012103c65a6e4a66a4a6b4af981c5e81632bb2d7336bc75d7ccf83e055006a2693050f00000000將前兩個字元從 02 更改為 03（版本 3）：
03000000000101fff8d9d39105eeec162fb45bd2a3e796b255866469a2cc7de93e438f3722c1490000000000fdffffff02801a0600000000001600145b497cfd64324fb0c4f7317472ca591cd7eb3bbfe093040000000000160014b1348ec3acd422b7c84f97f8757a0a5c3db9e32d02473044022020c3a9d7d06429008de82f13de672aac7886c5d6557a7c330bcb8cbc20b8cf4f02203890042ed8bf331e92f07df5d2a7bf5d8ade12cbb216f14493a98d0a188c4918012103c65a6e4a66a4a6b4af981c5e81632bb2d7336bc75d7ccf83e055006a2693050f00000000礦工使用塊中的版本來發出軟分叉準備就緒的信號。交易中可以有不同版本號的案例嗎？
根據這個答案：https ://bitcoin.stackexchange.com/a/72742 ，如果它不是 1 或 2，那麼交易不是標準的。所以我假設節點不會中繼另一個答案中提到的此類交易：https ://bitcoin.stackexchange.com/a/41008/ 。這很奇怪，因為事務中的一個欄位可以用於幾件事，但僅限於 1 和 2。如果所有版本都被認為是標準的並讓項目按照他們的意願使用它，是否有任何缺點？
它的最小值、最大值和無效值是多少？我嘗試使用
ff負 1 但它在版本中返回 255
確實，唯一的標準版本仍然是 1 和 2。交易版本號可以用來表示共識功能的支持。到目前為止，只有一個這樣的功能 - BIP 68。由於尚未定義和接受其他版本的特殊規則，標準規則將版本限制為 2 個已知版本號。但這並不意味著以後不能改變。就像我們如何擁有非標準的輸出腳本，但可以在未來的更新中成為標準，事務版本也是如此。
如果所有版本都被視為標準版本並讓項目按照他們的意願使用它，是否有任何缺點？
是的。因為事務版本可以控制如何對事務執行驗證，所以讓人們將版本設置為他們想要的任何內容可能會限制將來可以添加的功能或限制可以使用的版本號。但這也只是一個標準規則，所以如果礦工願意接受帶外交易，歡迎使用任何你想要的版本。
它的最小值、最大值和無效值是多少？我嘗試將 ff 用於負 1 但它在版本中返回 255
版本號是 4 個字節，而不是 1 個字節。它實際上是一個 32 位小端有符號整數（請注意，它被解析並儲存為有符號，而不是無符號，但轉換為無符號並在許多但不是所有地方用作無符號）。這使得它的最小值為-2147483648 == 0xffffffff，最大值為2147483647 == 0x7fffffff。