[SOLO] Got "stale" blocks, but there is no new block to solve for the next several minutes

[YetAnotherRussian]

Hi. Seems to be a problem in solo mode - these should not be stale as we do not receive new work aka block to solve for a long time after the block is found (up to 2 minutes). We do receive new gbt work, but it's the same block (prev block hash and targed confirms that).

I guess there should be either forced work restart (similar to the feature you did a few releases ago (cpuminer-opt-3.15.1: Force new work immediately after solving a block solo) or the ability to force send stale ones.

Some additional info:

I've tested v3.14.0 as I saw it should be:

So I guess these ones should be marked as rejected first. Will investigate further.

### UPD:. It seems that the coin cannot be solo mined with an external miner. The only issue I see here is that the reject reason is hidden in solo mode, so it took so much time to find out the problem.

Restoring this message like it was in v3.14.0 should be a good idea. Thanks.

P.S. I could provide further info on fixing this, if you'd be interested.

[JayDDee]

Stale detection is not precise. In stratum we parse the reject reason, solo often doesn't report a reject reason. When a share is rejected I test the ntime of the submitted share vs the current work. If they don't match I assume the share was rejected for being stale.

I think I can improve it if I don't assume solo has NULL reject reason. It wil fix this instance so it reports rejected as well as the reason. A reject solo with NULL reason will be reported as stale if ntime doesn't match.

Here'e the code change if you want to give it a try:

cpu-miner.c line 1194

// NEW
if ( reason ) stale = strstr( reason, "job" ); else stale = work ? work->data[ algo_gate.ntime_index ] != g_work.data[ algo_gate.ntime_index ] : false; // END NEW

// DELETE
// stale = work ? work->data[ algo_gate.ntime_index ] != g_work.data[ algo_gate.ntime_index ] : false; // if ( reason ) stale = stale || strstr( reason, "job" ); // END DELETE

[YetAnotherRussian]

solo often doesn't report a reject reason

I think so. The reasons I got above could be found somewhere here https://github.com/Bitcreds/Bitcreds/blob/master/src/main.cpp starting from line 2889

I'll grab the full log using "--debug --protocol-dump" to see what we actually get in the response.

I also see that nethash is not parsed or something:

[2021-01-21 10:28:16] JSON protocol response:
{
   "error": null,
   "result": {
      "difficulty": 0.039759869438866197,
      "errors": "",
      "currentblocksize": 1000,
      "currentblocktx": 0,
      "pooledtx": 0,
      "blocks": 985607,
      "genproclimit": 28,
      "networkhashps": 1417190.0364866499,
      "generate": false,
      "testnet": false,
      "chain": "main",
      "hashespersec": 0
   },
   "id": 8
}
[2021-01-21 10:28:16] Mining info: diff 0.03976, net_hashrate 0.000000, height 985607

So the nethash should be somewhere near 1.35Mh/s but not 0.000000

UPD.:

[2021-01-21 10:32:12] Threads restarted for new work.
[2021-01-21 10:32:14] DEBUG: hash <= target
Hash:   00000004f0fb16e6a3feac6b55bbaaeb63591334defc4446978cfb13397fdf67
Target: 00000019268e0000000000000000000000000000000000000000000000000000
[2021-01-21 10:32:14] 1 Submitted Diff 0.20237, Block 985608, Ntime fb2d0960
[2021-01-21 10:32:14] JSON protocol request:
{"method": "submitblock", "params": ["000000203785ff6125eacb1f93b5bcc55390cbf25a5be69de044c57d090b81441800000040ceeea277a174b87e86d44a067836fc5e3511e166bd86647b6202794129d1d8fb2d09608e26191dadb706820101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0403080a0fffffffff0180ba953e000000001976a914192d9321cef55e05a33798b00ee718663cd4a3d588ac00000000"], "id":4}


[2021-01-21 10:32:14] JSON protocol response:
{
   "error": null,
   "result": "bad-cb-amount",
   "id": 4
}
[2021-01-21 10:32:14] 1 A0 Stale 1 R0 B0, 788.680 sec (40ms)
                      Diff 0.20237 (5.09), Block 985608
[2021-01-21 10:32:14] Reject reason: bad-cb-amount
                      Hash:   00000004f0fb16e6a3fec000...
                      Target: 00000019268e000000000000...
[2021-01-21 10:32:17] JSON protocol request:
{"method": "getblocktemplate", "params": [{"capabilities": ["coinbasetxn", "coinbasevalue", "longpoll", "workid"], "rules": ["segwit"]}], "id":0}


[2021-01-21 10:32:17] JSON protocol response:
{
   "error": null,
   "result": {
      "transactions": [],
      "vbavailable": {},
      "mutable": [
         "time",
         "transactions",
         "prevblock"
      ],
      "masternode": {
         "payee": "CTkRhdCpVcwnA4fGm7MrXnczehtSne9z7x",
         "script": "76a9147bca06915815a206b047dfb48b54b96a989fbf7388ac",
         "amount": 600000000
      },
      "longpollid": "0000001844810b097dc544e09de65b5af2cb9053c5bcb5931fcbea2561ff85371881",
      "version": 536870912,
      "mintime": 1611213326,
      "masternode_payments_enforced": false,
      "fundreward": {
         "payee": "CPhPudPYNC8uXZPCHovyTyY98Q6fJzjJLm",
         "script": "76a9144f56c722b42f29034df6b2626f0ff45b7b03101d88ac",
         "amount": 50000000
      },
      "coinbasevalue": 1050000000,
      "sizelimit": 4194304,
      "height": 985608,
      "superblocks_started": true,
      "capabilities": [
         "proposal"
      ],
      "rules": [
         "csv"
      ],
      "masternode_payments_started": true,
      "previousblockhash": "0000001844810b097dc544e09de65b5af2cb9053c5bcb5931fcbea2561ff8537",
      "vbrequired": 0,
      "coinbaseaux": {
         "flags": ""
      },
      "superblocks_enabled": false,
      "target": "00000019268e0000000000000000000000000000000000000000000000000000",
      "curtime": 1611214336,
      "noncerange": "00000000ffffffff",
      "sigoplimit": 83886,
      "bits": "1d19268e",
      "superblock": []
   },
   "id": 0
}
[2021-01-21 10:32:17] Current block is 985608
[2021-01-21 10:32:17] JSON protocol request:
{"method": "getmininginfo", "params": [], "id":8}


[2021-01-21 10:32:17] JSON protocol response:
{
   "error": null,
   "result": {
      "difficulty": 0.039759869438866197,
      "errors": "",
      "currentblocksize": 1000,
      "currentblocktx": 0,
      "pooledtx": 0,
      "blocks": 985607,
      "genproclimit": 28,
      "networkhashps": 1417190.0364866499,
      "generate": false,
      "testnet": false,
      "chain": "main",
      "hashespersec": 0
   },
   "id": 8
}

That's how we get the response:

{
   "error": null,
   "result": "bad-cb-amount",
   "id": 4
}

[JayDDee]

The code you referenced looks like it's specific to bitcreds and probably requires special support in the miner.

The zero net_hashrate doesn't make sense. In get_mininginfo net_hashrate is assigned from the networkhashps field of the getmininginfo method, and it's clearly not zero in the protocol dump.

These 2 things look unrelated but I don't know what I can do about either of them.

I can still make the change to look for a reject reason to avoid a rejected share being reported as stale.

[JayDDee]

I think I iunderstand the zero net_hashrate problem. In the protocol dump networkhashps is a floating point number but get_mininginfo thinks it's an integer. I assume most coins use integer since this is original code and such a bug would have been discovered long ago. This appears to be another bitcreds customization.

It's an easy fix to handle both integer and floating point networkhashps but it still won't solve the reject problem.

I don't think there's anything I can do about solo mining bitcreds. There may be other surprises in the protocol.

[YetAnotherRussian]

Well, I think that fix for reject reason may be left for the next release... probably.

The other thing about BitCreds is a future fork to argon2d16000 (end of this month). See hash.h here: https://github.com/Bitcreds/Bitcreds/commit/38729ef3b5458e49faf5fe861ab89519fb5e244c

I think it should be better to add that support and just forget about solo. I'm unsure how GPUs will perform with these settings, so it may be a good idea to mine with cpuminer-opt.

I'm not sure if you are interested (those settings may be implemented as a user-defined, like for scrypt).

[JayDDee]

I won't be supporting the new algo. Bitcreds isn't worth it, it's been dropped by many pools.

I will, however, make the 2 changes discussed above. They are low risk and could help solo mining other algos.

[JayDDee]

v3.15.6 is released. There's no need to retest because the coin has since changed algos and is no longer supported.