NOMP BiblePay Pool: Stratum requested work restart

Recently, BiblePay released an external miner (a fork of minerd by pooler, aka cpuminer).

This has been working great for solo mining with and without anti-bot-net (ABN).

Now that solo mining is working well, BiblePay is improving code to allow the miner to work with stratum and the NOMP pool.

[2019-10-26 09:36:07] < {"id":null,"method":"mining.set_difficulty","params":[3]}
[2019-10-26 09:36:07] < {"id":null,"method":"mining.notify","params":["d34",null,"random.biblepay.hash","",null,"00000000","1b06e75c","5db475f7",true]}
[2019-10-26 09:36:08] < {"id":2,"result":true,"error":null}
[2019-10-26 09:36:08] Stratum requested work restart

Should I be concerned about stratum requested work restart?

No.

The stratum server decides when to send new work to the miner.

pooler said:

A few work restarts per minute are totally normal. Besides, it’s the server that decides when the client should start working on a new job, and there’s nothing you can do about that.

When a new block is found, stratum asks client to start on new work.

If you see restart followed by stratum from pool 0 detected new block you know the block was just mined and miner needs to start work on the new block.

evilpete says:

The short version is that the work to produce the “next” block depends on the previous block.  The moment a new block is found, any in-progress searching is aborted because it won’t produce anything useful.  This is important because it encourages a “found” block to be used and distributed quickly.

You should see this message each time the … network as a whole finds a new block.

The miner and pool software is constantly evolving so the performance and usefulness of the web site (e.g. stats) should improve over time.

In BiblePay version 1.4.5.1b, Rob added an enhancement to getblockforstratum where the merkle root changes every second due to randomization of the extraNonce field with a random integer. In previous versions, the merkle root would not change unless the block height changed. This previously made receiving unique blocks from the pool to miners very difficult. This also helps to mitigate bugs in NOMP where some miners were submitting different case (upper case instead of lower case) of share data to make it seem the pool was receiving a unique share. The cheat is mitigated by issuing a new merkleroot after a share is accepted. It does create more bandwidth demand, but with NOMP being fully tested, it is better to be cautious.

With every acceptable share submitted to the pool, the stratum requests a work restart for that miner (or perhaps entire thread on NOMP) and authorizes the miner again in the pool. Duplicate shares are still possible, but they tend to be from different miners in the same thread number. The most common error now will be job not found (stale share) which can happen if the miner submits a share from the old merkle root and does not realize a new “block” is available.

To keep the pool efficient, it is really the miner’s job to change things like the nTime to have more work to exhaust before requesting more from the pool or until the pool announces a block height change.