<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki" rel="nofollow noreferrer">BIP148</a> was not a soft fork deployment on its own, so it did not have a <a href="https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki" rel="nofollow noreferrer">BIP9</a> version bits signal associated with it.</p>

<p>The actual softfork deployment was SegWit itself, defined in <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki" rel="nofollow noreferrer">BIP141</a> and signalled by bit 1 in the version field.</p>

<p>Any block signaling soft fork readiness with BIP9 must have the top three bits set to <code>001</code>:</p>

<p><a href="https://github.com/bitcoin/bitcoin/blob/a79bca2f1fb25f433d6e100a31a3acfde2656ce1/src/versionbits.h#L14" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/blob/a79bca2f1fb25f433d6e100a31a3acfde2656ce1/src/versionbits.h#L14</a></p>

<pre><code>/** What bits to set in version for versionbits blocks */
static const int32_t VERSIONBITS_TOP_BITS = 0x20000000UL;
</code></pre>

<p>Readiness for SegWit was signaled by bit 1 or <code>1 &lt;&lt; 1</code> in 32-bit hexadecimal: <code>0x00000002</code></p>

<p>Therefore all blocks signaling SegWit during the BIP9 STARTED phase had the version <code>0x20000002</code></p>

<p>In Bitcoin the block version number is serialized as little-endian, meaning on the wire and on disk the first few bytes of a SegWit signaling block look like this:</p>

<pre><code>bitcoin-cli getblock 000000000000000000f288b3ff879d0ef11d3197f88dcdc1e29c3933b9c0e5af 0

0200002038493522351788...
</code></pre>

<p>Note the expected version bits in the first four bytes, little-endian.</p>

<p>To address your question specifically about the version in binary, all SegWit-signaling blocks would have a version field like this (shown here as big-endian to match your example)</p>

<pre><code>00100000 00000000 00000000 00000010
</code></pre>

<p>Miners do crazy things and some miners during this time signaled extra bits for various other reasons, but the two bits shown here must be set to signal SegWit.</p>

<p>On to the question of BIP148: It had no extra signals except for ASCII strings encoded in the coinbase scriptSig. In <a href="https://blockstream.info/block/000000000000000000f288b3ff879d0ef11d3197f88dcdc1e29c3933b9c0e5af" rel="nofollow noreferrer">block 469345</a> the coinbase scriptSig is:</p>

<pre><code>03612907236808005fe905fcc10000bf33092f736c7573682f4249503134382f
</code></pre>

<p>Which, decoded to ASCII:</p>

<pre><code>a)#_i|A?3       /slush/BIP148/
</code></pre>

<p>BIP148 nodes also included a similar string in their user-agents. Otherwise they provided no signal to the network that they would reject non-SegWit-signaling blocks after the flag date. They required no network majority to enforce their rules.</p>

CC BY-SA 4.0
2020-06-09T11:24:44.630Z
2020-06-09T11:24:44.630Z
pinhead
<p>Under BIP141 (SegWit), you could signal support by setting nVersion bit 1 equal to 1. BIP9 counted:</p>

<ul>
<li><p>20000002 1000000000000000000000000000<strong>1</strong>0</p></li>
<li><p>20000012 1000000000000000000000000100<strong>1</strong>0</p></li>
<li><p>30000007 1100000000000000000000000001<strong>1</strong>1</p></li>
</ul>

<p>Under BIP148 (Mandatory SegWit), it says <em>"all blocks must set the nVersion header top 3 bits to 001 together with bit field (1&lt;&lt;1) (according to the existing segwit deployment."</em> </p>

<p>What exactly should the nVersion have looked like? Which of these would be counted towards BIP148?</p>

<ul>
<li>001000000000000000000000000010 ?</li>
<li>100000000000000000000000000010 ?</li>
</ul>

<mining-theory><segregated-witness><protocol><miner-configuration><consensus>
How were miners supposed to signal support for BIP148?
Aman Saggu
# How were miners supposed to signal support for BIP148?

(Asked by: username_0 on 2020-06-07)

Under BIP141 (SegWit), you could signal support by setting nVersion bit 1 equal to 1. BIP9 counted:

* 20000002 1000000000000000000000000000**1**0
* 20000012 1000000000000000000000000100**1**0
* 30000007 1100000000000000000000000001**1**1

Under BIP148 (Mandatory SegWit), it says *"all blocks must set the nVersion header top 3 bits to 001 together with bit field (1<<1) (according to the existing segwit deployment."*

What exactly should the nVersion have looked like? Which of these would be counted towards BIP148?

* 001000000000000000000000000010 ?
* 100000000000000000000000000010 ?

**Tags:** mining-theory, segregated-witness, protocol, miner-configuration, consensus


---

## 1 answers

### Answer by username_1 on 2020-06-09. Score: 1 | Accepted answer

[BIP148](https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki) was not a soft fork deployment on its own, so it did not have a [BIP9](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki) version bits signal associated with it.

The actual softfork deployment was SegWit itself, defined in [BIP141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) and signalled by bit 1 in the version field.

Any block signaling soft fork readiness with BIP9 must have the top three bits set to `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;

```

Readiness for SegWit was signaled by bit 1 or `1 << 1` in 32-bit hexadecimal: `0x00000002`

Therefore all blocks signaling SegWit during the BIP9 STARTED phase had the version `0x20000002`

In Bitcoin the block version number is serialized as little-endian, meaning on the wire and on disk the first few bytes of a SegWit signaling block look like this:

```
bitcoin-cli getblock 000000000000000000f288b3ff879d0ef11d3197f88dcdc1e29c3933b9c0e5af 0

0200002038493522351788...

```

Note the expected version bits in the first four bytes, little-endian.

To address your question specifically about the version in binary, all SegWit-signaling blocks would have a version field like this (shown here as big-endian to match your example)

```
00100000 00000000 00000000 00000010

```

Miners do crazy things and some miners during this time signaled extra bits for various other reasons, but the two bits shown here must be set to signal SegWit.

On to the question of BIP148: It had no extra signals except for ASCII strings encoded in the coinbase scriptSig. In [block 469345](https://blockstream.info/block/000000000000000000f288b3ff879d0ef11d3197f88dcdc1e29c3933b9c0e5af) the coinbase scriptSig is:

```
03612907236808005fe905fcc10000bf33092f736c7573682f4249503134382f

```

Which, decoded to ASCII:

```
a)#_i|A?3       /slush/BIP148/

```

BIP148 nodes also included a similar string in their user-agents. Otherwise they provided no signal to the network that they would reject non-SegWit-signaling blocks after the flag date. They required no network majority to enforce their rules.


---

