<blockquote>
  <p>I know that pool operators have the power to modify the actual blocks inside a transaction. </p>
</blockquote>

<p>Transactions don't contain blocks. Miners/pool operators can't modify any of the normal transactions inside of a block. They can only change things in the block header, the coinbase transaction, and the transaction ordering.</p>

<blockquote>
  <p>I also know that pool operators can decide on block transaction orderings and even commit double spends pretty easily. I know that pool operators send the merkle root hash of this block to miners. The miner then provides the nonce, which is the hard work of mining.</p>
</blockquote>

<p>Not necessarily. It depends on the protocol being used. If it is stratum, this is largely true (except the merkle root thing. Stratum only provides part of the merkle tree for the merkle root so that an extranonce in the coinbase can be used.)</p>

<p>If getblocktemplate is used, the miner has a lot of control over what is being hashed. With GBT, instead of just part of the header and hashed data being sent to the miner, the entire block structure is sent and the miner constructs the block and block header himself before hashing it. This means that the miner could choose to change whatever he wants in the block.</p>

<blockquote>
  <p>But, there's another part to mining, which is the block version number. Do most pool operators set this, for e.g. voting, and which bits are able to be set for votes? </p>
</blockquote>

<p>If the pool is using stratum without ASICBOOST support, then the pool operator sets the bits for the miner. If ASICBOOST is supported, the miner can modify some of the bits in the version number in order to use ASICBOOST. With GBT, the miner can modify the version number if the pool indicates that they will accept a block with a version number different from the one that they set in the block template.</p>

<p>Also, note that miners do not vote. Setting the version number for soft forks is not a vote, it is signalling that the miner is prepared to enforce the rules of a soft fork. It is a signal of readiness, not a vote.</p>

CC BY-SA 4.0
2019-03-24T16:56:14.757Z
LOL sorry, I meant transactions inside a block. The entire post was written from a very tired brain. Also, version numbers can be interpreted as a vote.
nick carraway
CC BY-SA 4.0
2019-03-24T16:58:23.863Z
But they aren't used as one? It seems the coinbase parameter is the primary way to vote: https://bitcoin.stackexchange.com/questions/50446/what-are-the-possible-version-bits-votes
nick carraway
CC BY-SA 4.0
2019-03-24T16:27:00.463Z
2019-03-24T16:27:00.463Z
Ava Chow
<p>I know that pool operators have the power to modify the actual transactions in a block. I also know that pool operators can decide on block transaction orderings and even commit double spends pretty easily.  I know that pool operators send the merkle root hash of this block to miners. The miner then provides the nonce, which is the hard work of mining.</p>

<p>But, there's another part to mining, which is the block version number. Do most pool operators set this, for e.g. voting, and which bits are able to be set for votes?  </p>

<mining-pools><stratum>
Do pool operators usually set block version numbers before their clients hash?
nick carraway
# Do pool operators usually set block version numbers before their clients hash?

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

I know that pool operators have the power to modify the actual transactions in a block. I also know that pool operators can decide on block transaction orderings and even commit double spends pretty easily. I know that pool operators send the merkle root hash of this block to miners. The miner then provides the nonce, which is the hard work of mining.

But, there's another part to mining, which is the block version number. Do most pool operators set this, for e.g. voting, and which bits are able to be set for votes?

**Tags:** mining-pools, stratum


---

## 1 answers

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

> I know that pool operators have the power to modify the actual blocks inside a transaction.

Transactions don't contain blocks. Miners/pool operators can't modify any of the normal transactions inside of a block. They can only change things in the block header, the coinbase transaction, and the transaction ordering.

> I also know that pool operators can decide on block transaction orderings and even commit double spends pretty easily. I know that pool operators send the merkle root hash of this block to miners. The miner then provides the nonce, which is the hard work of mining.

Not necessarily. It depends on the protocol being used. If it is stratum, this is largely true (except the merkle root thing. Stratum only provides part of the merkle tree for the merkle root so that an extranonce in the coinbase can be used.)

If getblocktemplate is used, the miner has a lot of control over what is being hashed. With GBT, instead of just part of the header and hashed data being sent to the miner, the entire block structure is sent and the miner constructs the block and block header himself before hashing it. This means that the miner could choose to change whatever he wants in the block.

> But, there's another part to mining, which is the block version number. Do most pool operators set this, for e.g. voting, and which bits are able to be set for votes?

If the pool is using stratum without ASICBOOST support, then the pool operator sets the bits for the miner. If ASICBOOST is supported, the miner can modify some of the bits in the version number in order to use ASICBOOST. With GBT, the miner can modify the version number if the pool indicates that they will accept a block with a version number different from the one that they set in the block template.

Also, note that miners do not vote. Setting the version number for soft forks is not a vote, it is signalling that the miner is prepared to enforce the rules of a soft fork. It is a signal of readiness, not a vote.

> **Comments:**
> **username_0**: LOL sorry, I meant transactions inside a block. The entire post was written from a very tired brain. Also, version numbers can be interpreted as a vote.  
> **username_0**: But they aren't used as one? It seems the coinbase parameter is the primary way to vote: https://bitcoin.stackexchange.com/questions/50446/what-are-the-possible-version-bits-votes  

---

