<p>The block version number has traditionally been the way for miners to signal their readiness to enforce a soft fork. The version number was likely used because of its historical use for soft fork signalling. Also, the version number does not indicate that a particular set of rules are active for a block. In fact, the version bit used by Segwit is no longer set by miners (besides those using ASICBOOST) since Segwit has activated.</p>

<p>Additionally, the version number helps SPV wallets know when segwit is active so that they can use it. Otherwise SPV wallets would have to download entire blocks in order to examine the Coinbase transaction in order to do so, which would largely defeat their primary benefit.</p>

<p>Full nodes don't really benefit from the version number being used as the signal. However when deploying any kind of fork, consideration must be made for everyone in the ecosystem. Using the version number does not hurt full nodes, has some extra benefits of not taking up block space for transactions themselves, and lest SPV wallets know when the fork activates.</p>

<blockquote>
  <p>I thought Segwit was about transaction ordering in the actual block</p>
</blockquote>

<p>No. Segwit does not effect transaction ordering at all. It changes the format of transactions and how certain output scripts are validated.</p>

<blockquote>
  <p>Other than protecting those values for future forks, does Segwit require any special consideration by SPV wallets / miners?</p>
</blockquote>

<p>Yes. SPV wallets need to know when Segwit activated so that they know when they can make and accept transactions containing Segwit inputs and outputs.</p>

CC BY-SA 4.0
2019-03-26T00:17:28.450Z
Yea I forgot that SPV wallets' outgoing data might be improved by this header. I was only thinking about the incoming sync
nick carraway
CC BY-SA 4.0
2019-03-24T23:30:05.173Z
2019-03-24T23:30:05.173Z
Ava Chow
<p>Block headers are special because they're synced by SPV wallets. They're also part of the mining algorithm used by miners, which can enable controversial things like ASIC boost.</p>

<p>However, in the case of Segwit, the block version number was chosen to indicate the Segwit softfork. What was the advantage of including this value in the block header's version number field as opposed to in the coinbase transaction?</p>

<p>To be specific, does the Segwit soft fork affect the work done by SPV wallets or by ASICs, other than preventing ASICBoost in the latter case? </p>

<p>If the Segwit soft fork was put in the version number because "thats what version numbers are for" and "ASIC boost is bad", I'm okay with that being the reason. I even consider that a technical reason -- there may be a future soft fork that affects SPV wallets that those verison numbers are needed for, and putting the Segwit value in the block header helps protects those values (as opposed to sacrificing them to ASICboost). I'm just trying to understand what kind of soft forks might affect SPV wallets, or if I'm missing anything else.</p>

<p>I thought Segwit was about transaction ordering in the actual block, which could indicate the Merkle Root part of the header should be processed differently by full nodes. But if the full block is being received anyway, with the coinbase, why couldn't the segwit indicator just be put in the coinbase? (Aside from protecting those values)</p>

<p>I would just like to know whether I'm missing anything here. Other than protecting those values for future forks, does Segwit require any special consideration by SPV wallets / miners?  Is there any reason why the coinbase transaction couldn't be used for this particular soft fork other than future technical developments?</p>

<mining-pools>
How does a full node benefit from receiving a block with a version number in its header?
nick carraway
# How does a full node benefit from receiving a block with a version number in its header?

(Asked by: username_0 on 2019-03-24)

Block headers are special because they're synced by SPV wallets. They're also part of the mining algorithm used by miners, which can enable controversial things like ASIC boost.

However, in the case of Segwit, the block version number was chosen to indicate the Segwit softfork. What was the advantage of including this value in the block header's version number field as opposed to in the coinbase transaction?

To be specific, does the Segwit soft fork affect the work done by SPV wallets or by ASICs, other than preventing ASICBoost in the latter case?

If the Segwit soft fork was put in the version number because "thats what version numbers are for" and "ASIC boost is bad", I'm okay with that being the reason. I even consider that a technical reason -- there may be a future soft fork that affects SPV wallets that those verison numbers are needed for, and putting the Segwit value in the block header helps protects those values (as opposed to sacrificing them to ASICboost). I'm just trying to understand what kind of soft forks might affect SPV wallets, or if I'm missing anything else.

I thought Segwit was about transaction ordering in the actual block, which could indicate the Merkle Root part of the header should be processed differently by full nodes. But if the full block is being received anyway, with the coinbase, why couldn't the segwit indicator just be put in the coinbase? (Aside from protecting those values)

I would just like to know whether I'm missing anything here. Other than protecting those values for future forks, does Segwit require any special consideration by SPV wallets / miners? Is there any reason why the coinbase transaction couldn't be used for this particular soft fork other than future technical developments?

**Tags:** mining-pools


---

## 1 answers

### Answer by username_1 on 2019-03-24. Score: 3 | Accepted answer

The block version number has traditionally been the way for miners to signal their readiness to enforce a soft fork. The version number was likely used because of its historical use for soft fork signalling. Also, the version number does not indicate that a particular set of rules are active for a block. In fact, the version bit used by Segwit is no longer set by miners (besides those using ASICBOOST) since Segwit has activated.

Additionally, the version number helps SPV wallets know when segwit is active so that they can use it. Otherwise SPV wallets would have to download entire blocks in order to examine the Coinbase transaction in order to do so, which would largely defeat their primary benefit.

Full nodes don't really benefit from the version number being used as the signal. However when deploying any kind of fork, consideration must be made for everyone in the ecosystem. Using the version number does not hurt full nodes, has some extra benefits of not taking up block space for transactions themselves, and lest SPV wallets know when the fork activates.

> I thought Segwit was about transaction ordering in the actual block

No. Segwit does not effect transaction ordering at all. It changes the format of transactions and how certain output scripts are validated.

> Other than protecting those values for future forks, does Segwit require any special consideration by SPV wallets / miners?

Yes. SPV wallets need to know when Segwit activated so that they know when they can make and accept transactions containing Segwit inputs and outputs.

> **Comments:**
> **username_0**: Yea I forgot that SPV wallets' outgoing data might be improved by this header. I was only thinking about the incoming sync  

---

