1

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

  • 20000002 100000000000000000000000000010

  • 20000012 100000000000000000000000010010

  • 30000007 110000000000000000000000000111

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 ?
1

BIP148 was not a soft fork deployment on its own, so it did not have a BIP9 version bits signal associated with it.

The actual softfork deployment was SegWit itself, defined in BIP141 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 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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.