<p>With the Stratum V1 protocol in use today (and the Stratum V2 protocol as it is currently proposed), mining pools actually send the parts of the coinbase transaction to their miners for those miners to modify. Specifically, they reserve space in their coinbase transactions for miners to use as an extra nonce. Those miners will construct the coinbase transaction, insert their extra nonce, compute the merkle root (they are given merkle branches to be able to complete the merkle root), and then create the block header.</p>
<p>However when the miner submits their work, they are only submitting the pieces that they added - namely the nonce, the timestamp, and the extra nonce. The pool will then reconstruct the coinbase transaction with the given extra nonce, reconstruct the merkle root, reconstruct the block header, and verify that the block header meets the PoW requirement for that miner. If the coinbase transaction had been modified by the miner, or by an attacker who sits between the pool and the miner, then it is unlikely that the block hash they calculate for that submitted share will meet the PoW requirement for that miner.</p>
<p>It is unlikely that miners are using <code>createrawtransaction</code> for creating their coinbase transactions as it is unable to do so anyways. <code>createrawtransaction</code> does not allow the caller to set an input's <code>vout</code> to be the right value for a coinbase transaction. So mining pool software are most likely creating the coinbase transaction internally rather than outsourcing it to bitcoind. In that case, they will be using the correct outputs. If they aren't, then either something is manipulating the coinbase transaction after the pool sends it but before the miner receives it, or the attacker is able to directly modify the pool software's memory.</p>
<p>In the first case, the PoW checking I described earlier is the protection. In any case, the pool can't really do much about an external entity (by external, I mean external to the pool software, it could still be running on the same compromised machine) modifying the coinbase when they send it out. In the second case, the pool can't protect against that as the attacker can just always make the software think that their coinbase is correct.</p>

CC BY-SA 4.0
2021-05-13T03:56:22.520Z
2021-05-13T03:56:22.520Z
Ava Chow
<p>Pools creates their own coinbase transaction to pay their selves, and they begin the PoW by hashing different Headers, what prevent a hacker from changing the createrawtransaction with different output (His bitcoin adress instaed of the pool bitcoin pool adress)?</p>
<p>How pools can know that the header they are providing for miners contains a merkle root which contains a coinbase transaction created with a valid ouput (Their bitcoin adress and not another adress)?</p>
<p>Thanks</p>

CC BY-SA 4.0
2021-05-12T23:16:19.490Z
If a hasher takes the work given by a pool, and modifies it to pay themselves instead of the pool, then their block shares just won't be counted as valid work by the pool, and thus won't get any reward. Is that the scenario you're concerned about?
Pieter Wuille
CC BY-SA 4.0
2021-05-12T23:24:26.100Z
No, i dont mean that, i mean how the pool knows that the header they provided for hashers is valid one
Hamita
CC BY-SA 4.0
2021-05-12T23:25:30.443Z
They create it themselves? They obviously have to trust their own software, or they have a problem.
Pieter Wuille
CC BY-SA 4.0
2021-05-12T23:27:30.287Z
Yes, but the software will communicate with the bitcoin core, the software will submit an RPC to build the coinbase transaction, i mean in that moment what prevents a hacker of manipulating that ouput? if he did it, how pools verify that? constantly?
Hamita
CC BY-SA 4.0
2021-05-12T23:28:41.417Z
If the pool's operations have been infiltrated by a hacker that has access to all their internal systems, then they have a problem. If not, then there is no such problem.
Pieter Wuille
CC BY-SA 4.0
2021-05-12T23:31:23.723Z
Yes, thank you for your clarification :-)
Hamita
CC BY-SA 4.0
2021-05-12T23:35:25.687Z
I mean... this is literally the same as everywhere, and not specific to mining, bitcoin, cryptocurrency, or even financial services in general at all. If your infrastructure is hacked, you have a problem.
Pieter Wuille
CC BY-SA 4.0
2021-05-12T23:41:52.920Z
Yes, i understand, by my question i thought that pools check constantly if the headers they provides to miners contains their correct coinbase transaction
Hamita
<security><mining-pools><coinbase-transaction>
Did pools verify constantly the ouput of createrawtransaction when they build their coinbase transaction?
Hamita
# Did pools verify constantly the ouput of createrawtransaction when they build their coinbase transaction?

(Asked by: username_0 on 2021-05-12)

Pools creates their own coinbase transaction to pay their selves, and they begin the PoW by hashing different Headers, what prevent a hacker from changing the createrawtransaction with different output (His bitcoin adress instaed of the pool bitcoin pool adress)?

How pools can know that the header they are providing for miners contains a merkle root which contains a coinbase transaction created with a valid ouput (Their bitcoin adress and not another adress)?

Thanks

**Tags:** security, mining-pools, coinbase-transaction

> **Comments:**
> **username_1**: If a hasher takes the work given by a pool, and modifies it to pay themselves instead of the pool, then their block shares just won't be counted as valid work by the pool, and thus won't get any reward. Is that the scenario you're concerned about?  
> **username_0**: No, i dont mean that, i mean how the pool knows that the header they provided for hashers is valid one  
> **username_1**: They create it themselves? They obviously have to trust their own software, or they have a problem.  
> **username_0**: Yes, but the software will communicate with the bitcoin core, the software will submit an RPC to build the coinbase transaction, i mean in that moment what prevents a hacker of manipulating that ouput? if he did it, how pools verify that? constantly?  
> **username_1**: If the pool's operations have been infiltrated by a hacker that has access to all their internal systems, then they have a problem. If not, then there is no such problem.  
> **username_0**: Yes, thank you for your clarification :-)  
> **username_1**: I mean... this is literally the same as everywhere, and not specific to mining, bitcoin, cryptocurrency, or even financial services in general at all. If your infrastructure is hacked, you have a problem.  
> **username_0**: Yes, i understand, by my question i thought that pools check constantly if the headers they provides to miners contains their correct coinbase transaction  

---

## 1 answers

### Answer by username_2 on 2021-05-13. Score: 2 | Accepted answer

With the Stratum V1 protocol in use today (and the Stratum V2 protocol as it is currently proposed), mining pools actually send the parts of the coinbase transaction to their miners for those miners to modify. Specifically, they reserve space in their coinbase transactions for miners to use as an extra nonce. Those miners will construct the coinbase transaction, insert their extra nonce, compute the merkle root (they are given merkle branches to be able to complete the merkle root), and then create the block header.

However when the miner submits their work, they are only submitting the pieces that they added - namely the nonce, the timestamp, and the extra nonce. The pool will then reconstruct the coinbase transaction with the given extra nonce, reconstruct the merkle root, reconstruct the block header, and verify that the block header meets the PoW requirement for that miner. If the coinbase transaction had been modified by the miner, or by an attacker who sits between the pool and the miner, then it is unlikely that the block hash they calculate for that submitted share will meet the PoW requirement for that miner.

It is unlikely that miners are using `createrawtransaction` for creating their coinbase transactions as it is unable to do so anyways. `createrawtransaction` does not allow the caller to set an input's `vout` to be the right value for a coinbase transaction. So mining pool software are most likely creating the coinbase transaction internally rather than outsourcing it to bitcoind. In that case, they will be using the correct outputs. If they aren't, then either something is manipulating the coinbase transaction after the pool sends it but before the miner receives it, or the attacker is able to directly modify the pool software's memory.

In the first case, the PoW checking I described earlier is the protection. In any case, the pool can't really do much about an external entity (by external, I mean external to the pool software, it could still be running on the same compromised machine) modifying the coinbase when they send it out. In the second case, the pool can't protect against that as the attacker can just always make the software think that their coinbase is correct.


---

