0

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

Improve this question
8
  • 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
    May 12, 2021 at 23:16
  • No, i dont mean that, i mean how the pool knows that the header they provided for hashers is valid one
    – Hamita
    May 12, 2021 at 23:24
  • 1
    They create it themselves? They obviously have to trust their own software, or they have a problem.
    – Pieter Wuille
    May 12, 2021 at 23:25
  • 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
    May 12, 2021 at 23:27
  • 2
    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
    May 12, 2021 at 23:28

1 Answer 1

Reset to default
2

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.

Improve this answer
0

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.