0

In a mining pool where rewards are distributed according to the fraction of hashrate contributed to the pool, could a miner misbehave trying cheating in some way? And are there strategies to prevent this?

I can think of one example:

Bad behavior 1

A miner with 1TH/s could pretend to be mining at 2TH/s by sending to the pool at regular time intervals the block headers (here I am not sure what the miner actually sends to the pool if the header or just the nonce) he is discovering plus a bunch of other headers already found in previous iterations.

Solution 1

This behavior does not affect the the ability of the pool to mine a block, but just inflates the reward of the bad miner, basically stealing from the other miners' share. It can be prevented if the pool keeps a lookup table of the block hashes coming from each miner and check for repeated blocks, though this seems like overkill and too expensive. Another solution could be enforcing that the miner sends the block solutions in an increasing order of the nonces, that's would be easy to verify and no repeated blocks are possible.

Lagrang3
  • 130
  • 6

2 Answers2

1

From How is the network hash rate calculated? we can see that we can calculate the applied hashrate of an entity from the network difficulty and the number of blocks produced in a specific period (e.g. in a day). The entity in the linked question is the whole bitcoin network but the method can be applied to a single node. The entity cannot fake this hashrate because they have to present sufficient blocks with hashes less than the required target.

In any reasonable measurement period (e.g. a day), a typical pool member will not produce any hashes at the current Bitcoin network target. But if the pool asks the members to present blocks with hashes less than an easier target, every period the member will be able to produce many blocks meeting that easier target. The pool operator can therefore measure contributed hashrate. As you pointed out, the pool operator has to check that hashes are not repeated. To prevent collusion each pool member would need to include a unique marker in their template so that the pool operator can check.

Note that the method used by the pool member to mine blocks is completely independent of target, so they do exactly the same process for an easier target that they do for a harder target. So occasionally, one of the blocks with a hash lower than the pool's target will also be lower than the Bitcoin network target. This pays to the pool operator who can distribute the money according to contributed hashrate as measured at the pool target.

RedGrittyBrick
  • 26,841
  • 3
  • 25
  • 51
1

If the pool didn't keep a lookup table of every outstanding bit of work it offered to miners, it couldn't submit the complete block if the miner successfully found a block header. So mining pools must already keep track of all outstanding work units they've given to miners for as long as they are willing to accept shares for those work units.

David Schwartz
  • 51,554
  • 6
  • 106
  • 178
  • I don't understand what exactly the pool is keeping on a lookup table. – Lagrang3 Oct 11 '23 at 06:59
  • @Lagrange.el.Ciencia The blocks that it asked the miners to mine. It needs a different one for each work unit it gives out or all miners would be repeating the same computations. – David Schwartz Oct 11 '23 at 21:01
  • Not the entire block, at least the block header, or just the fields in the header that are used to change the block hash. – Lagrang3 Oct 12 '23 at 17:46
  • @Lagrange.el.Ciencia If it doesn't store the entire block, it cannot submit the block to the network if the block is successfully mined. So it must store the entire block. The blocks must be different or the miners will all be doing the same work. – David Schwartz Oct 16 '23 at 01:00