哪個 nVersion 位是“硬分叉位”？

2015 年 BIP 草案建議使用“硬分叉位”：

nVersion 中的最高有效位被定義為硬分叉位。目前，此標頭位設置為 1 的塊是無效的，因為 BIP34 將 nVersion 解釋為有符號數並要求它 >=2（對於 BIP66，>=3）。在塊頭的 640 位中，這是唯一一個固定且沒有任何用途的位，因此是指示部署硬分叉的最佳方式。

<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009576.html>

如果位索引從左到右增加，那麼我想像硬分叉位佔據索引 31，標記*如下（nVersion是一個 32 位值）。

0                   1                   2                   3
0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1
                                                             *

根據提議，設置第 31 位nVersion應該會導致塊被拒絕為無效。

BIP-9 對可用位進一步限制，具體來說，位 0-2 必須設置為 [0, 0, 1]：

處於 STARTED 狀態的塊會獲得一個 nVersion，其位位置位設置為 1。此類塊的前 3 位必須為 001，因此實際可能的 nVersion 值的範圍是 [0x20000000…0x3FFFFFFF]，包括在內。

<https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki>

此外，BIP-9 按從右到左升序排列版本位。也就是說，版本位 0 是nVersion位 31，版本位 1 是nVersion位 30，依此類推。

但如果是這種情況，那麼版本位 0 將是禁區。BIP-9 對此隻字未提，實際上 BIP-68 使用版本位 0 發出信號：

此 BIP 將由“versionbits”BIP9 使用位 0 部署。

<https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki>

我的問題很簡單：

1. 鑑於我上面的圖表，哪個nVersion位索引是“硬分叉位”？
2. 如果我的解釋是正確的（我不相信我是正確的），那麼如何在不導致這樣做的塊被拒絕為無效的情況下發出 BIP-68 信號？

更新：我困惑的根源是認為nVersion位索引和版本位索引執行的方向相反。不要。例如，要使用版本位 1 表示已準備好提案，nVersion則設置位 1。BIP-9 的規則在nVersion檢測到簽名時啟動。此簽名的第 29-31 位分別設置為1、0和0。這會使第 31 位未設置。

彼得的回答解決了上面的問題（1）。

至於問題 (2) BIP-68 信號不會導致塊拒絕，因為設置的是位 0，而不是位 31。

位 31 有時被稱為硬分叉位。

BIP34 將版本號限制為 2 或更高。由於塊版本是 32 位有符號整數，設置其最高位會導致負數，這將違反 BIP34。

結果，對該位的任何使用都會導致對規則的向後不兼容的更改——硬分叉——這對系統中的所有參與者來說都是顯而易見的。

引用自：https://bitcoin.stackexchange.com/questions/57844