礦工應該如何表示對 BIP148 的支持?
在 BIP141 (SegWit) 下,您可以通過將 nVersion 位 1 設置為 1 來表示支持。 BIP9 計數:
- 20000002 1000000000000000000000000000 1 0
- 20000012 1000000000000000000000000100 1 0
- 30000007 1100000000000000000000000001 1 1
在 BIP148(強制隔離見證)下,它說*“所有塊必須將 nVersion 頭的前 3 位連同位欄位 (1<<1) 一起設置為 001(根據現有的隔離見證部署。”*
nVersion 究竟應該是什麼樣子?其中哪些將計入 BIP148?
- 001000000000000000000000000010 ?
- 100000000000000000000000000010 ?
BIP148本身不是軟分叉部署,因此它沒有與之關聯的BIP9版本位信號。
實際的軟分叉部署是 SegWit 本身,在BIP141中定義並由版本欄位中的位 1 發出信號。
任何帶有 BIP9 的軟分叉準備好的塊信號都必須將前三位設置為
001
:<https://github.com/bitcoin/bitcoin/blob/a79bca2f1fb25f433d6e100a31a3acfde2656ce1/src/versionbits.h#L14>
/** What bits to set in version for versionbits blocks */ static const int32_t VERSIONBITS_TOP_BITS = 0x20000000UL;
SegWit 準備就緒由位 1 或
1 << 1
32 位十六進製表示:0x00000002
因此,在 BIP9 STARTED 階段發送 SegWit 信號的所有塊都有版本
0x20000002
在比特幣中,塊版本號被序列化為 little-endian,這意味著在網路上和磁碟上,SegWit 信號塊的前幾個字節如下所示:
bitcoin-cli getblock 000000000000000000f288b3ff879d0ef11d3197f88dcdc1e29c3933b9c0e5af 0 0200002038493522351788...
注意前四個字節中的預期版本位,little-endian。
為了專門解決您關於二進製版本的問題,所有 SegWit 信號塊都將具有這樣的版本欄位(此處顯示為 big-endian 以匹配您的範例)
00100000 00000000 00000000 00000010
礦工做瘋狂的事情,在此期間,一些礦工出於各種其他原因發出額外的比特信號,但這裡顯示的兩個比特必須設置為 SegWit 信號。
關於 BIP148 的問題:除了在 coinbase scriptSig 中編碼的 ASCII 字元串之外,它沒有額外的信號。在塊 469345中,coinbase scriptSig 是:
03612907236808005fe905fcc10000bf33092f736c7573682f4249503134382f
其中,解碼為 ASCII:
a)#_i|A?3 /slush/BIP148/
BIP148 節點也在其使用者代理中包含一個類似的字元串。否則,他們不會向網路提供他們將在標誌日期之後拒絕非 SegWit 信號塊的信號。他們不需要網路多數人來執行他們的規則。