This post answers some common problems people have when operating or using a mining pool. Note that those answers below are the common cause. There might be other rare causes of the problems that I’m not aware of. I would really appreciate it if you can share your situations if you think it is one of the later.

Faking Timestamps

I heard that it is possible to fake the block timestamp when mining, like shifting the system clock a little bit, to gain advantage of mining rewards. Is that true?

No. No matter how the miner choose to shift the timestamp, it hurts the miner.

Timestamp, besides the not-recommended TIMESTAMP opcode in EVM, is only used for one thing – to calculate the block difficulty for the next block. Miners first finalize a block (which also set a timestamp for the block), and then start the Proof of Work algorithm ethash. When the miner is lucky and the algorithm is finished, the miner then broadcast the block.

During this process, what if the miner shift its block timestamp a little bit in the past? Well, not a lot would happen. The block would be accepted without problem, as long as the shifted timestamp is still after the previous block’s timestamp. However, in this case, the miner also cannot gain any advantage – the difficulty for the next block would be raised higher than normal, thus makes it harder than normal to mine the next block. So a rational miner will not do that.

What if the miner shift its block timestamp a little bit to the future? This is basically gambling for the miner because all current Ethereum full nodes also have another consensus rule – that if a block’s timestamp is in the future relative to the system clock, then it is rejected. You can test this by slightly shift your system clock by one minute to the past. Now run your Parity or Geth client, you will see that the node will start to reject valid network blocks, because it thinks that they’re mined “in the future” and thus breaks the consensus rules.

So there is indeed a really small window, between a block is finalized, and the block is mined, that the miner can choose to shift its block timestamp. First, this is really tricky because for a miner, if it has already mined the block but the actual world clock has not yet passed the set block timestamp, it would need to withheld the block until then, and during this time, cannot mine new blocks. This hurts the profit of the miner. What if the miner is smart enough to always set the timestamp before when the block is mined? In this case, it is equivalent to the miner withheld its hashrate – I claim that I mined this block using this amount of time, but the actual time I spent is shorter. However, a side effect of a miner doing this is that its block difficulty would be lower. In chain selection, we always choose the chain with the most accumulated difficulty (called “total difficulty”). By withhelding hashrates, the miner risks losing the competition and its block risks to get orphaned.

In conclusion, both shifting the block timestamp to the future, and shifting the block timestamp to the past hurt the miner, rather than helping them to gain rewards.

Block Orphan Rates

I heard that I can reduce my mining pool’s block orphan rate by reducing the amount of transactions I include in a block to the point to including no transactions. Is this true?

Yes, but you’re also likely to lose transaction fees, so there is a trade-off.

Every transaction you included in a block has costs. The first cost is when the client executes the transaction. The second, and the largest cost is the network propogation time. The more transactions you include, the larger the block size, hence the longer the network propogation time. As a result, just because of the additional one or two seconds, other miners might get a block from your competitors first, and then decide to build new block on top of that instead of yours. Small pools should especially be cautious about this.

This is the marginal transaction cost. And for a mining pool, it is important to set the mining block transaction gas limit to a point near the optimal one. It is usually not zero – by including no transactions you also lose transaction fees that you might get. It also might not be the maximum current block gas limit, because by doing that, the marginal transaction cost is too high that it overall becomes negative. Setting a good mining block transaction gas limit is not a easy job for miners right now, however. While Gavin Anderson has done some study about the marginal transaction cost for the Bitcoin blockchain, we lack similar studies of it for Ethereum-like blockchain. So this job for you currently might involve some trail and error.

Besides marginal transaction cost, you might also consider just reduce the network propogation time. Doing this is much simpler. Get your machine on a location with higher Internet bandwidth, or get multiple full nodes in different locations for your mining pool.

In conclusion, you can get optimal profit from your mining pool by setting a good mining block gas limit depending on your marginal transaction cost, and try different ways to reduce the network propogation time.

Next: Parity Multisig Hack and Ethereum Classic

November 7, 2017

Is Ethereum Classic Vulnerable to Parity Multisig Hack?

Previous: SputnikVM, the Rux Microkernel, and Embedded Devices

October 17, 2017

Running SputnikVM on the Rux microkernel using Rust's no_std feature.

Up: Classic in Orbit