An (even more) optimized version of cpuminer (pooler's cpuminer, CPU-only)

[PSL]

I am sorry to write this but GBT submit doesn't work. I haven't found any new block from the time I run cpuminer 2.4. When I use "--no-gbt", blocks are found and accepted...

I use powercoin (https://github.com/Powercoin/Powercoin) to test it. Powercoin is dead coin with very low difficulty, good to test solo mining. Powercoin code was not updated for a while so it could be a source of problem but I assume code is good enough to replicate this problem.

When cpuminer tries to submit GBT block, block is rejected with 404 error.

Code:

[2014-05-24 10:42:20] HTTP request failed: The requested URL returned error: 404
[2014-05-24 10:42:20] submit_upstream_work json_rpc_call failed

I tried to mine with "--coinbase-addr=xx" and "--coinbase-addr=xx --coinbase-sig=yy" and blocks are rejected in both cases.

When I mine with "--no-gbt", blocks are accepted

Code:

[2014-05-24 11:02:52] accepted: 1/1 (100.00%), 4.83 khash/s (yay!!!)

Example of "rejected" GBT block:

Code:

[2014-05-24 10:57:55] JSON protocol request:
{"method": "submitblock", "params": ["01000000e65ab64270079fbca476b71bfce63f647b
9fd6ad518606cac7fc1399f0b1602f8f6bd269a664a8b6b0c0db263ee954192316678c33d0c1f9a0
0ee00f1842204f317b805350d9011ea0000de5010100000001000000000000000000000000000000
0000000000000000000000000000000000ffffffff140305c9020f3564656162353063062f503253
482fffffffff0100286bee000000001976a914f650f1ee4beb5f988696abddb3150a9f4bfdb93288
ac00000000"], "id":1}

* Re-using existing connection! (#0) with host powerminer
* Connected to powerminer (54.87.211.179) port 9863 (#0)
* Server auth using Basic with user 'PWC'
> POST / HTTP/1.1
Authorization: Basic TU0uUFdDOjlKUVh1VFVjNmVrNzRGV2EyeUVYN1JIYzg1ckhEV0M3Wkp3bWpCdjdwU3Ni
Host: powerminer:9863
Accept-Encoding: deflate, gzip
Content-Type: application/json
Content-Length: 423
User-Agent: cpuminer/2.4
X-Mining-Extensions: midstate

* The requested URL returned error: 404
* Closing connection #0

[pooler]

When cpuminer tries to submit GBT block, block is rejected with 404 error.

Apparently your daemon does not implement the submitblock method, even though it is part of the non-optional sections of BIP 22.

As a matter of fact, I've mined several blocks on the Litecoin testnet, so I know that the GBT implementation of 2.4 is not (entirely) broken.

[PSL]

When cpuminer tries to submit GBT block, block is rejected with 404 error.

Apparently your daemon does not implement the submitblock method, even though it is part of the non-optional sections of BIP 22.

As a matter of fact, I've mined several blocks on the Litecoin testnet, so I know that the GBT implementation of 2.4 is not (entirely) broken.

Interesting... :-( Is it possible to test availability of submitblock method by a submit of random data after cpuminer start?

[pooler]

Interesting... :-( Is it possible to test availability of submitblock method by a submit of random data after cpuminer start?

It is certainly possible, but it would be a bit pointless in my opinion. If a server provides a getblocktemplate method but no submitblock method, then it is violating the official specifications.

[PSL]

Interesting... :-( Is it possible to test availability of submitblock method by a submit of random data after cpuminer start?

It is certainly possible, but it would be a bit pointless in my opinion. If a server provides a getblocktemplate method but no submitblock method, then it is violating the official specifications.

I checked that Powercoin has really no code to support submitblock method. But it supports getblocktemplate method... XENcoin has newer code than Powercoin but it is similar case. Craftcoin is even newer but has similar problem... :-(

BTW, the submitblock method is defined in source file src/bitcoinrpc.cpp. If it is not there, coin cannot accept GBT blocks.

[PSL]

I patched Powercoin with submitblock; I get the code from Noblecoin... I am not sure that the patch is perfect but it "works", I can mine in GBT mode. I see these problems now:

1) block is accepted but it is not assigned to address defined by cpuminer (listreceivedbyaddress reports 0.00)
2) block is added to total balance and it is visible in listtransactions
3) cpuminer reports this:

Code:

[2014-05-24 20:38:13] accepted: 0/1 (0.00%), 4.24 khash/s (booooo)

And these are details:

Code:

[2014-05-24 20:38:13] DEBUG: hash <= target
Hash:   0000011765198ac5ad42387fa26ced7b4ca049e17f6c2bef46f316a0379c5a06
Target: 000001d950000000000000000000000000000000000000000000000000000000
[2014-05-24 20:38:13] JSON protocol request:
{"method": "submitblock", "params": ["0100000007ee5bd17c4de91cf366b17a1f7972f6e7
b3554fb30d10df961e6a861601797373c351cf872223622531d84580ee236be2ff11016d9bfff875
5bacd4a1060fe514e7805350d9011ec0000112010100000001000000000000000000000000000000
0000000000000000000000000000000000ffffffff140318c9020f3536323663633765062f503253
482fffffffff0100286bee000000001976a91494049e424a5cdcfdb0bb3b07fee1abecfda382cc88
ac00000000"], "id":1}

* Re-using existing connection! (#0) with host testcoin
* Connected to testcoin (192.168.222.80) port 9863 (#0)
* Server auth using Basic with user 'PWC'
> POST / HTTP/1.1
Authorization: Basic UFdDOnJwY1BTTHBhc3M=
Host: testcoin:9863
Accept-Encoding: deflate, gzip
Content-Type: application/json
Content-Length: 423
User-Agent: cpuminer/2.4
X-Mining-Extensions: midstate

< HTTP/1.1 200 OK
< Date: Sat, 24 May 2014 18:39:02 +0000
< Connection: keep-alive
< Content-Length: 36
< Content-Type: application/json
< Server: powercoin-json-rpc/v0.6.3.0-unk-beta
< 
* Connection #0 to host testcoin left intact
[2014-05-24 20:38:13] JSON protocol response:
{
   "error": null,
   "result": true,
   "id": 1
}
[2014-05-24 20:38:13] accepted: 0/1 (0.00%), 4.24 khash/s (booooo)

Is there some explanation, why cpuminer reports 0/1 (0.00%) and not 1/1 (100.00%)??

[pooler]

Code:

[2014-05-24 20:38:13] JSON protocol response:
{
   "error": null,
   "result": true,
   "id": 1
}
[2014-05-24 20:38:13] accepted: 0/1 (0.00%), 4.24 khash/s (booooo)

The server implementation you are using is faulty. According to the specs, submitblock should never return a result of "true".
The result must be "null" when a submitted block is accepted, and that's why cpuminer considers any other result as a rejection. ("accepted: 0/1" means that you submitted 1 blocks, and 0 of them got accepted.)

[PSL]

I found that Franko (FRK) coin works in GBT mode well.

I tried to mine with several cpuminers those were mining to the same address and had no signature configured and those miners were finding different blocks, I was not observing collisions. I still don't understand that signature feature...

[pooler]

I tried to mine with several cpuminers those were mining to the same address and had no signature configured and those miners were finding different blocks, I was not observing collisions. I still don't understand that signature feature...

It is actually pretty easy to produce a collision if the difficulty is low enough: just start two miners of about the same speed and try to keep the getblocktemplate calls synchronized. That way the two miners will be working on the exact same headers (same timestamp, same merkle root hash).
Out of curiosity, I tried this just now on the Litecoin testnet, and I was able to obtain a double submission (one accepted, one rejected) within a few minutes.

[PSL]

I want to report, that cpuminer found a block and I cannot see it in the "listtransactions" report... I mined Franko (FRK), GBT mode with address and no signature. I don't have cpuminer detail log but I have debug.log from frankod. cpuminer and server are running on the same PC. From the log file I have I assume it is some problem with frankod...

cpuminer:

Code:

[2014-05-25 16:54:33] 4 miner threads started, using 'scrypt' algorithm.
[2014-05-26 07:13:06] accepted: 1/1 (100.00%), 15.11 khash/s (yay!!!)

debug.log (frankod):

Code:

(2014-05-26 07:12:58)
received block 4ab88852eb336e3a41b69deb2ef2839f67ef42fc3c91c99b818234aa590321f0
Difficulty Retarget - Kimoto Gravity Well
PastRateAdjustmentRatio = 0.914426
Before: 1d012d37  000000012d370000000000000000000000000000000000000000000000000000
After:  1d012d2c  000000012d2c5e4c2f497d0fd4dc657cc90a0638d3d2ecd9a1906b4b6c9bb015
Committing 1 changed transactions to coin database...
SetBestChain: new best=4ab88852eb336e3a41b69deb2ef2839f67ef42fc3c91c99b818234aa590321f0  height=741280  log2_work=51.204934  tx=866957  date=2014-05-26 05:12:58 progress=0.999998
ProcessBlock: ACCEPTED
getblocks -1 to 0000000000000000000000000000000000000000000000000000000000000000 limit 500
getblocks -1 to 0000000000000000000000000000000000000000000000000000000000000000 limit 500
getblocks -1 to 0000000000000000000000000000000000000000000000000000000000000000 limit 500
getblocks -1 to 0000000000000000000000000000000000000000000000000000000000000000 limit 500

ThreadRPCServer method=submitblock

Difficulty Retarget - Kimoto Gravity Well
PastRateAdjustmentRatio = 0.914426
Before: 1d012d37  000000012d370000000000000000000000000000000000000000000000000000
After:  1d012d2c  000000012d2c5e4c2f497d0fd4dc657cc90a0638d3d2ecd9a1906b4b6c9bb015
ProcessBlock: ACCEPTED
getblocks -1 to 0000000000000000000000000000000000000000000000000000000000000000 limit 500
getblocks -1 to 0000000000000000000000000000000000000000000000000000000000000000 limit 500
CreateNewBlock(): total size 1000
Difficulty Retarget - Kimoto Gravity Well
PastRateAdjustmentRatio = 0.919932
Before: 1d012d2c  000000012d2c0000000000000000000000000000000000000000000000000000
After:  1d012b8b  000000012b8b374f0329161f9add3c0ca4587e6b74f0329161f9add3c0ca4585

(2014-05-26 07:13:02)
received block b17f7ab98a1fe9739ddecba1fb992b61cc12ab8438390ee54d62bfddb99cbe6b
Difficulty Retarget - Kimoto Gravity Well
PastRateAdjustmentRatio = 0.919932
Before: 1d012d2c  000000012d2c0000000000000000000000000000000000000000000000000000
After:  1d012b8b  000000012b8b374f0329161f9add3c0ca4587e6b74f0329161f9add3c0ca4585
Committing 1 changed transactions to coin database...
SetBestChain: new best=b17f7ab98a1fe9739ddecba1fb992b61cc12ab8438390ee54d62bfddb99cbe6b height=741281  log2_work=51.204936  tx=866958  date=2014-05-26 05:13:02 progress=0.999992
ProcessBlock: ACCEPTED

Block founded by my cpuminer should be between blocks 741280 add 741281 but it is not there. I see ProcessBlock: ACCEPTED but block is missing and I cannot explain it...

Code:

$ frankod getblockhash 741280
4ab88852eb336e3a41b69deb2ef2839f67ef42fc3c91c99b818234aa590321f0
$ frankod getblockhash 741281
b17f7ab98a1fe9739ddecba1fb992b61cc12ab8438390ee54d62bfddb99cbe6b

After this experience, I will mine with --no-gbt parameter...

I found similar situation when block was really accepted. debug.log is different in this case, I see message Committing 1 changed transactions to coin database...:

Code:

received getdata for: block 10718ea1b6085cd6dd23b885432299e2b6caca83f3ae31fc7899c90dd41cc7b2
getblocks -1 to 0000000000000000000000000000000000000000000000000000000000000000 limit 500
getblocks -1 to 0000000000000000000000000000000000000000000000000000000000000000 limit 500
getblocks -1 to 0000000000000000000000000000000000000000000000000000000000000000 limit 500
getblocks -1 to 0000000000000000000000000000000000000000000000000000000000000000 limit 500
getblocks -1 to 0000000000000000000000000000000000000000000000000000000000000000 limit 500
getblocks -1 to 0000000000000000000000000000000000000000000000000000000000000000 limit 500
ThreadRPCServer method=submitblock
Difficulty Retarget - Kimoto Gravity Well
PastRateAdjustmentRatio = 0.96709
Before: 1d013248  0000000132480000000000000000000000000000000000000000000000000000
After:  1d01319b  00000001319ba70336589c6b80db65bd2a63711babab573fca3edee7e2639b2b
AddToWallet 028ebced569d05b28f8fc4c79eaeb5753da593025b2fd8cccceba625faccef05  new
Committing 1 changed transactions to coin database...
SetBestChain: new best=5453e3528d550b8fd297cc6f3780b25a3aab3a97f3a5b6a8c2ab6d18a3cbe4b9  height=739480  log2_work=51.200899  tx=864616  date=2014-05-25 14:03:53 progress=0.999998
ProcessBlock: ACCEPTED

[komozinek]

Hi guys, pls, can anyone help me ?

I want to mine X11 with this miner and i am geting error (in link) Any ideas what to do ?

http://jyxo.info/uploads/18/1832c867aeb97b0cb5702fcadbeead5f6db31929.jpg

[Massimo80]

Hi guys, pls, can anyone help me ?

I want to mine X11 with this miner and i am geting error (in link) Any ideas what to do ?

http://jyxo.info/uploads/18/1832c867aeb97b0cb5702fcadbeead5f6db31929.jpg

Where did you get the impression cpuminer supports X11?!?

[usao]

Does minerd support X11 coins or Scrypt only?

[qhy]

Does minerd support X11 coins or Scrypt only?

yes，  i want to know whether cpu minerd suppport x11 coins or not?

and who can tell me which cpu minerd support x11??

[pooler]

I want to mine X11 with this miner and [...]

Does minerd support X11 coins or Scrypt only?

Please read the FAQ in the first post.

and who can tell me which cpu minerd support x11??

Google.

[konradp]

Hi Pooler and everybody who understands the code:)! May I have a few questions?

I'm trying to analyze your code. I need to do that to create a pool. I have problems with understanding "difficulty", but please bear in mind that I read all(?) available sources related to this topic. Btw - My job is limited to stratum functionality.

1. I understand that stratum_gen_work function (cpu-miner.c) generates a new "work" when we reached max value of nonce. But what are the values in lines 692 & 693:
work->data[20] = 0x80000000;
work->data[31] = 0x00000280;
What these values do?

2. Where is the code responsible for finding a hash? In cpu-miner.c (line 780) I can see this:
work.data[19]++
It looks like incrementing nonce. But I can't see a place where you actually generate a hash and then send it to a pool server. I mean I can see a function called workio_submit_work which takes struct workio_cmd as an argument, but there is no hash variable in it.

I would be very grateful for answering these questions.

[kmsalex]

Is scrypt n:2048 supported? I don't see any way to lunch it in the usage instructions...

[konradp]

Thanks for the interest.

The algorithm in use is sha256d.

Pooler already answered my questions on github:

1. Those values are part of standard SHA-2 padding. You need not worry about them.
2. Hashing is delegated to the scanhash_* functions.

I'm analyzing the scanhash_sha256d function now, and I'll probably have more questions:)

[usao]

Forgive my ignorance, but what algos are supported? I dont see a list in the OP...

[konradp]

Forgive my ignorance, but what algos are supported? I dont see a list in the OP...

AFAIK scrypt and sha256d