Hi,

What is the command line for using your own Bicoin Core? RPC is enabled.

I tried this: --algo sha256d --url http://localhost --threads 1 --coinbase-addr ADDRESS

I get this error: [2024-07-29 15:18:54] Enabled optimizations: SSE2 [2024-07-29 15:18:54] CPU affinity [!!] [2024-07-29 15:18:54] 1 of 2 miner threads started using 'sha256d' algorithm [2024-07-29 15:18:54] JSON decode failed(1): '[' or '{' expected near '<' [2024-07-29 15:18:54] getblocktemplate failed, falling back to getwork [2024-07-29 15:18:54] JSON decode failed(1): '[' or '{' expected near '<' [2024-07-29 15:18:54] json_rpc_call failed, retry after 10 seconds

Even tried this and the result is the same --url http://localhost:8332 --url http://127.0.0.1 --url http://127.0.0.1:8332

From the Bitcoin Core Console, the "getblocktemplate" works. Any suggesting?

Jul 29 '24 13:07 scorpim

On the surface this looks like cpuminer received a malformed message which JSON couldn't parse. I suggest adding --debug and --protocol-dump options to get more data including the raw message. Solo mining has always been hit or miss. I can't test it as easily as stratum. Cpuminer may be missing some new features. You could try with tpruvot's or pooler's version of cpuminer to see if they work. I don't know what address format you were using but you could try with a legacy address to see if that works. Another possibilty is a regression. Try older versions of cpuminer, some GBT changes were made around v3.21 & 3.22, bech32 support was added in v3.16.2, see RELEASE NOTES for version details.

Jul 29 '24 16:07 JayDDee

Thanks for the reply!

I tried 3 ways now with --debug --protocol-dump You can reuse this address, I'm not using it, this is just for test. Give you even the private key incase you hit jackpot :))) 1AQU5KHyJS4V3Aj6ErHTYhYLHwTh7cY6pt KwTqyoJXUzgABoEXNwZ6yj3ZCm2xjmAX6bctdZdPjojzJdsBkby6

I tried tpruvot / cpuminer-multi -> want work poolers miner / minerd -> want work [2024-07-29 20:53:28] HTTP request failed: The requested URL returned error: 401

I'm using Bitcoin Core GUI v27.0.0 (latest) on Windows 10. I tried other miner binaries too, not just this in the examples.

It looks like some 'Unauthorized' issue, but I'm not using any user/passwd. From the Console it works, even from the DOS command prompt. Strange...

PS: "falling back to getwork", 'getwork' is depricated with newer Bitcoin Core.

There is a Bitcoin configurator: https://jlopp.github.io/bitcoin-core-config-generator/

I'll try to google around for 'working' programs how they do it if you have no ideas.

I hope this debug feedback helps ->

	Test 1: WITH LOCALHOST
cpuminer-sse2 --debug --protocol-dump --algo sha256d --url http://localhost:8332 --threads 1 --coinbase-addr 1AQU5KHyJS4V3Aj6ErHTYhYLHwTh7cY6pt

[2024-07-29 20:18:45] Coinbase address uses B58 coding [2024-07-29 20:18:45] CPU affinity [!!] [2024-07-29 20:18:45] 1 of 2 miner threads started using 'sha256d' algorithm [2024-07-29 20:18:45] Default miner thread priority 0 (nice 19) [2024-07-29 20:18:45] Binding thread 0 to cpu 0 [2024-07-29 20:18:45] JSON protocol request: {"method": "getblocktemplate", "params": [{"capabilities": ["coinbasetxn", "coinbasevalue", "longpoll", "workid"], "rules": ["segwit"]}], "id":0}

Trying ::1:8332...
TCP_NODELAY set
Connected to localhost (::1) port 8332 (#0)
Server auth using Basic with user ''

POST / HTTP/1.1 Host: localhost:8332 Authorization: Basic Og== Accept: / Accept-Encoding: identity Content-Type: application/json User-Agent: cpuminer-opt-24.2-x64W X-Mining-Extensions: longpoll reject-reason Content-Length: 147

upload completely sent off: 147 out of 147 bytes
Mark bundle as not supporting multiuse < HTTP/1.1 401 Unauthorized
Authentication problem. Ignoring this. < WWW-Authenticate: Basic realm="jsonrpc" < Date: Mon, 29 Jul 2024 18:18:45 GMT < Content-Length: 0 < Content-Type: text/html; charset=ISO-8859-1 <
Connection #0 to host localhost left intact [2024-07-29 20:18:45] Empty data received in json_rpc_call. [2024-07-29 20:18:45] getblocktemplate failed, falling back to getwork [2024-07-29 20:18:45] JSON protocol request: {"method": "getwork", "params": [], "id":0}
Found bundle for host localhost: 0xa36a60 [serially]
Re-using existing connection! (#0) with host localhost
Connected to localhost (::1) port 8332 (#0)
Server auth using Basic with user ''

POST / HTTP/1.1 Host: localhost:8332 Authorization: Basic Og== Accept: / Accept-Encoding: identity Content-Type: application/json User-Agent: cpuminer-opt-24.2-x64W X-Mining-Extensions: longpoll reject-reason Content-Length: 45

upload completely sent off: 45 out of 45 bytes
Mark bundle as not supporting multiuse < HTTP/1.1 401 Unauthorized
Authentication problem. Ignoring this. < WWW-Authenticate: Basic realm="jsonrpc" < Date: Mon, 29 Jul 2024 18:18:45 GMT < Content-Length: 0 < Content-Type: text/html; charset=ISO-8859-1 <
Connection #0 to host localhost left intact [2024-07-29 20:18:45] Empty data received in json_rpc_call. [2024-07-29 20:18:45] json_rpc_call failed, retry after 10 seconds [2024-07-29 20:18:55] JSON protocol request: {"method": "getwork", "params": [], "id":0}
Found bundle for host localhost: 0xa36a60 [serially]
Re-using existing connection! (#0) with host localhost
Connected to localhost (::1) port 8332 (#0)
Server auth using Basic with user ''

POST / HTTP/1.1 Host: localhost:8332 Authorization: Basic Og== Accept: / Accept-Encoding: identity Content-Type: application/json User-Agent: cpuminer-opt-24.2-x64W X-Mining-Extensions: longpoll reject-reason Content-Length: 45

	Tets 2: WITH 127.0.0.1
cpuminer-sse2 --debug --protocol-dump --algo sha256d --url http://127.0.0.1:8332 --threads 1 --coinbase-addr 1AQU5KHyJS4V3Aj6ErHTYhYLHwTh7cY6pt

[2024-07-29 20:25:52] Coinbase address uses B58 coding [2024-07-29 20:25:52] CPU affinity [!!] [2024-07-29 20:25:52] 1 of 2 miner threads started using 'sha256d' algorithm [2024-07-29 20:25:52] Default miner thread priority 0 (nice 19) [2024-07-29 20:25:52] Binding thread 0 to cpu 0 [2024-07-29 20:25:52] JSON protocol request: {"method": "getblocktemplate", "params": [{"capabilities": ["coinbasetxn", "coinbasevalue", "longpoll", "workid"], "rules": ["segwit"]}], "id":0}

Trying 127.0.0.1:8332...
TCP_NODELAY set
Connected to 127.0.0.1 (127.0.0.1) port 8332 (#0)
Server auth using Basic with user ''

POST / HTTP/1.1 Host: 127.0.0.1:8332 Authorization: Basic Og== Accept: / Accept-Encoding: identity Content-Type: application/json User-Agent: cpuminer-opt-24.2-x64W X-Mining-Extensions: longpoll reject-reason Content-Length: 147

upload completely sent off: 147 out of 147 bytes
Mark bundle as not supporting multiuse < HTTP/1.1 401 Unauthorized
Authentication problem. Ignoring this. < WWW-Authenticate: Basic realm="jsonrpc" < Date: Mon, 29 Jul 2024 18:25:52 GMT < Content-Length: 0 < Content-Type: text/html; charset=ISO-8859-1 <
Connection #0 to host 127.0.0.1 left intact [2024-07-29 20:25:52] Empty data received in json_rpc_call. [2024-07-29 20:25:52] getblocktemplate failed, falling back to getwork [2024-07-29 20:25:52] JSON protocol request: {"method": "getwork", "params": [], "id":0}
```
  Test 3: WITHOUT PORT NUMBER (My HTTP server turns up)
```
cpuminer-sse2 --debug --protocol-dump --algo sha256d --url http://127.0.0.1 --threads 1 --coinbase-addr 1AQU5KHyJS4V3Aj6ErHTYhYLHwTh7cY6pt

[2024-07-29 20:31:15] Coinbase address uses B58 coding [2024-07-29 20:31:15] CPU affinity [!!] [2024-07-29 20:31:15] 1 of 2 miner threads started using 'sha256d' algorithm [2024-07-29 20:31:15] Default miner thread priority 0 (nice 19) [2024-07-29 20:31:15] Binding thread 0 to cpu 0 [2024-07-29 20:31:15] JSON protocol request: {"method": "getblocktemplate", "params": [{"capabilities": ["coinbasetxn", "coinbasevalue", "longpoll", "workid"], "rules": ["segwit"]}], "id":0}

Trying 127.0.0.1:80...
TCP_NODELAY set
Connected to 127.0.0.1 (127.0.0.1) port 80 (#0)
Server auth using Basic with user ''

POST / HTTP/1.1 Host: 127.0.0.1 Authorization: Basic Og== Accept: / Accept-Encoding: identity Content-Type: application/json User-Agent: cpuminer-opt-24.2-x64W X-Mining-Extensions: longpoll reject-reason Content-Length: 147

upload completely sent off: 147 out of 147 bytes
Mark bundle as not supporting multiuse < HTTP/1.1 200 OK < Date: Mon, 29 Jul 2024 18:31:15 GMT < Server: Apache/2.4.56 (Win64) OpenSSL/1.1.1t PHP/8.3.7 < Last-Modified: Sun, 28 Jul 2024 15:24:52 GMT < ETag: "7842-61e505894a3a3" < Accept-Ranges: bytes < Content-Length: 30786 < Content-Type: text/html <
Connection #0 to host 127.0.0.1 left intact [2024-07-29 20:31:15] JSON decode failed(1): '[' or '{' expected near '<' [2024-07-29 20:31:15] getblocktemplate failed, falling back to getwork [2024-07-29 20:31:15] JSON protocol request: {"method": "getwork", "params": [], "id":0}
Found bundle for host 127.0.0.1: 0xdf6c60 [serially]
Re-using existing connection! (#0) with host 127.0.0.1
Connected to 127.0.0.1 (127.0.0.1) port 80 (#0)
Server auth using Basic with user ''

POST / HTTP/1.1 Host: 127.0.0.1 Authorization: Basic Og== Accept: / Accept-Encoding: identity Content-Type: application/json User-Agent: cpuminer-opt-24.2-x64W X-Mining-Extensions: longpoll reject-reason Content-Length: 45

upload completely sent off: 45 out of 45 bytes
Mark bundle as not supporting multiuse < HTTP/1.1 200 OK < Date: Mon, 29 Jul 2024 18:31:15 GMT < Server: Apache/2.4.56 (Win64) OpenSSL/1.1.1t PHP/8.3.7 < Last-Modified: Sun, 28 Jul 2024 15:24:52 GMT < ETag: "7842-61e505894a3a3" < Accept-Ranges: bytes < Content-Length: 30786 < Content-Type: text/html <
Connection #0 to host 127.0.0.1 left intact [2024-07-29 20:31:15] JSON decode failed(1): '[' or '{' expected near '<' [2024-07-29 20:31:15] json_rpc_call failed, retry after 10 seconds [2024-07-29 20:31:25] JSON protocol request: {"method": "getwork", "params": [], "id":0}
Connection 0 seems to be dead!
Closing connection 0
Hostname 127.0.0.1 was found in DNS cache
Trying 127.0.0.1:80...
TCP_NODELAY set
Connected to 127.0.0.1 (127.0.0.1) port 80 (#1)
Server auth using Basic with user ''

POST / HTTP/1.1 Host: 127.0.0.1 Authorization: Basic Og== Accept: / Accept-Encoding: identity Content-Type: application/json User-Agent: cpuminer-opt-24.2-x64W X-Mining-Extensions: longpoll reject-reason Content-Length: 45

upload completely sent off: 45 out of 45 bytes
Mark bundle as not supporting multiuse < HTTP/1.1 200 OK < Date: Mon, 29 Jul 2024 18:31:25 GMT < Server: Apache/2.4.56 (Win64) OpenSSL/1.1.1t PHP/8.3.7 < Last-Modified: Sun, 28 Jul 2024 15:24:52 GMT < ETag: "7842-61e505894a3a3" < Accept-Ranges: bytes < Content-Length: 30786 < Content-Type: text/html <
Connection #1 to host 127.0.0.1 left intact [2024-07-29 20:31:25] JSON decode failed(1): '[' or '{' expected near '<' [2024-07-29 20:31:25] json_rpc_call failed, retry after 10 seconds

Jul 29 '24 20:07 scorpim

The original error message only occurs when connecting to port 80, using 8332 reports an empty reply. Make sure you're using the correct port.

As previously mentioned try a different address, one that doesn't use B58 coding, to see if it's related to that. Also try older versions of cpuminer-opt in case to rule out regressions. Check the server logs to find out why it's sending an empty reply. Ignore the fallback to getwork log, you can use --no-getwork to stop it if you like.

Jul 29 '24 22:07 JayDDee

If you try to connect to the wrong port with the miner, you get this error: HTTP request failed: Failed to connect to 127.0.0.1 port 12345: Connection refused

Miner is crashing when user/passwd set: cpuminer-sse2 --debug --protocol-dump --userpass minime:password2 --algo sha256d --url http://127.0.0.1:8332 --threads 1 --coinbase-addr YOURADDRESS

Result Output: [2024-07-30 20:30:32] JSON protocol request: {"method": "getblocktemplate", "params": [{"capabilities": ["coinbasetxn", "coinbasevalue", "longpoll", "workid"], "rules": ["segwit"]}], "id":0}

*   Trying 127.0.0.1:8332...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8332 (#0)
* Server auth using Basic with user 'minime'
> POST / HTTP/1.1
Host: 127.0.0.1:8332
Authorization: Basic aW1pOnBhc3N3b3JkMg==
Accept: */*
Accept-Encoding: identity
Content-Type: application/json
User-Agent: cpuminer-opt-24.2-x64W
X-Mining-Extensions: longpoll reject-reason
Content-Length: 147

* upload completely sent off: 147 out of 147 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: application/json
< Date: Tue, 30 Jul 2024 18:30:33 GMT
< Content-Length: 3620876
<
* Connection #0 to host 127.0.0.1 left intact
[2024-07-30 20:30:33]

And this is the point where the miner crashed.... Good news is that in the Bitcoin Core debug.log I see now: CreateNewBlock(): block weight: 3992542 txs: 3381 fees: 5926966 sigops 13073

So far my bitcoin.conf looks like this after a lot of different tests server=1 daemon=1

# Allow JSON-RPC connections from specified source.
rpcallowip=127.0.0.1
rpcport=8332
rpcbind=127.0.0.1:8332

# not necessary
rpcthreads=8

# without user/passwd you get "Unauthorized"
rpcuser=minime
rpcpassword=password2

Without user/passwd you get in the debug.log ThreadRPCServer incorrect password attempt from 127.0.0.1:

The miner output says: * upload completely sent off: 45 out of 45 bytes * Mark bundle as not supporting multiuse < HTTP/1.1 401 Unauthorized * Authentication problem. Ignoring this. * Connection #0 to host 127.0.0.1 left intact [2024-07-30 21:10:46] Empty data received in json_rpc_call. [2024-07-30 21:10:46] json_rpc_call failed, retry after 10 seconds

Tomorrow I'll try other binaries and programs. Any other tips?

Jul 30 '24 20:07 scorpim

OK, I GOT IT !!!

The "currentblockweight" is 4.000.000 large by default.

This has to be lowered down to 500.000

So the bitcoin.conf looks like this (Windows 10, Bitcoin Core GUI 27.0.0) # [rpc] server=1 # Allow JSON-RPC connections from specified source. rpcallowip=127.0.0.1 rpcport=8332 rpcbind=127.0.0.1:8332 # [mining] # This is the default and makes the miner to crash #blockmaxweight=4000000 # Lower it to this blockmaxweight=500000 rpcuser=minime rpcpassword=password2

This is why the miner crashing.

Can you look at the output to see if this is correct? Can I try to test for mining? Is this safe?

The command line is: cpuminer-sse2 --debug --protocol-dump --userpass minime:password2 --algo sha256d --url http://127.0.0.1:8332 --threads 1 --coinbase-addr 1AQU5KHyJS4V3Aj6ErHTYhYLHwTh7cY6pt

I'll test the other binaries tomorrow.

This is the miners output :

[2024-07-30 23:57:07] GBT: SegWit is enabled
[2024-07-30 23:57:08] JSON protocol request:
{"method": "getmininginfo", "params": [], "id":8}

* Found bundle for host 127.0.0.1: 0xdf67d0 [serially]
* Re-using existing connection! (#0) with host 127.0.0.1
* Connected to 127.0.0.1 (127.0.0.1) port 8332 (#0)
* Server auth using Basic with user 'minime'
> POST / HTTP/1.1
Host: 127.0.0.1:8332
Authorization: Basic bWluaW1lOnBhc3N3b3JkMg==
Accept: */*
Accept-Encoding: identity
Content-Type: application/json
User-Agent: cpuminer-opt-24.2-x64W
X-Mining-Extensions: longpoll reject-reason
Content-Length: 51

* upload completely sent off: 51 out of 51 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: application/json
< Date: Tue, 30 Jul 2024 21:57:08 GMT
< Content-Length: 211
<
* Connection #0 to host 127.0.0.1 left intact
[2024-07-30 23:57:08] JSON protocol response:
{
   "error": null,
   "result": {
	  "difficulty": 82047728459932.75,
	  "currentblocktx": 44,
	  "pooledtx": 3824,
	  "currentblockweight": 499916,
	  "blocks": 854720,
	  "networkhashps": 6.1541640004973822e20,
	  "chain": "main",
	  "warnings": ""
   },
   "id": 8
}
[2024-07-30 23:57:08] getmininginfo: difficulty 8.2048e+013, networkhashps 6.1542e+020, blocks 854720
[2024-07-30 23:57:08] GBT new work received in 248.00 ms
[2024-07-30 23:57:08] New Block 854721, Tx 44, Net Diff 19104, Ntime b361a966
					  Miner TTF @ 20.00 h/s 23y23d, Net TTF @ 615.42 Eh/s 0m00s
[2024-07-30 23:57:08] Threads restarted for new work.
[2024-07-30 23:57:10] CTRL_C_EVENT received, exiting
[2024-07-30 23:57:10] Program exit

I stopped the program because I donno if this is correct.

Jul 30 '24 22:07 scorpim

Looks good, you're getting new blocks to mine. Finding a block is nearly impossible but you can let it run without debug and protocol for a while if you're playing the lottery.

Jul 30 '24 22:07 JayDDee

Are you awake too?

You are right, it's impossible to mine, but I always wanted to see how this works. Connect a miner to my Bitcoin Core. Now I figured it out. "Too large block size" And now if someone is asking you "How to...", now you know too ;) It 'works' with a little re-writing in the conf file.

Will you do some coding to fix this crash issue?

Jul 30 '24 22:07 scorpim

In a previous life I validated all inputs to ensure my code would never crash due to someone else's error. For cpuminer I took the reverse approach, fast and loose and avoid anything that could slow it down. Since the crash is extremely rare, caused by a misconfiguration of an external program, and preventing the crash would require extra code that would run for every RPC reply (affecting performance) I choose not to make any changes.

How did you figure blockmaxweight=500000? This is the first I've heard of it, seems to be related to segwit but I don't know how it affects mining.

Edit: I should be more precise: it APPEARS to be caused by a misconfiguration. Since I don't understand the setting I don't know if the miner should be able to handle the default value. If cpuminer is deficient it will take some work to figure it out. If I'm lucky it will be easy to find and be something simple like enlarging a buffer. But I need to understand the parameter before I do anything.

Jul 31 '24 01:07 JayDDee

"In a previous life" :)) Got it, same here...

The crash is not external, it's the miner. How I figured it out? I saw this: < Date: Tue, 30 Jul 2024 18:30:33 GMT < Content-Length: 3620876 < * Connection #0 to host 127.0.0.1 left intact [2024-07-30 20:30:33] ..........And crashed...........

The "Content-Length", very large, I remembered I read it somewhere that the size of the blocks was smaller before. They increased it to 4 MB for more transactions per block (and CPU miners was written very long time ago). Also I wanted to see the JSON reply from the Bitcoin Core to see if it's correct, but it was to large. DOS buffer can't keep that much info. Then I remembered that I can reduce the size of the JSON reply from the server with "blockmaxweight". So I started to reduce it first with 1 MB at a time and restart the server every time. Under 1 MB started to reduce it with 100 K each time. And 500 K was the winner. "blockmaxweight=500000"

Now I have even tested it on my local network with an other PC to. I works great ! The trick is that in Bitcoins config file you have to add: rpcallowip=192.168.0.0/24 rpcbind=0.0.0.0

The miner can't take the default block size. Probably this "new" block size nobody noticed, since not many are mining with CPU anymore, definitely not solo or with your own Bitcoin Core. Or, if they tried and crashed, they ignored it, no bug report, just "quitted". But there was also a problem with the connection, that now we know how to fix. With all this info, probably more would like to try (for fun).

The performance is actually affected.... Before I tell you how, I have a silly question: What is hash/sec ? Is it nonce/sec ? ( YES, I really don't know! )

And now to the performance: With the --debug option I get this output: [2024-07-31 22:41:46] getmininginfo: difficulty 9.0667e+013, networkhashps 6.2433e+020, blocks 854856 [2024-07-31 22:41:46] GBT new work received in 98.27 ms [2024-07-31 22:41:46] New Block 854857, Tx 458, Net Diff 21110, Ntime 8aa1aa66 [2024-07-31 22:41:46] Threads restarted for new work. [2024-07-31 22:41:52] GBT: SegWit is enabled [2024-07-31 22:41:52] getmininginfo: difficulty 9.0667e+013, networkhashps 6.2433e+020, blocks 854856 [2024-07-31 22:41:52] GBT new work received in 840.53 ms [2024-07-31 22:42:06] GBT: SegWit is enabled [2024-07-31 22:42:09] getmininginfo: difficulty 9.0667e+013, networkhashps 6.2433e+020, blocks 854856 [2024-07-31 22:42:09] GBT new work received in 4484.58 ms [2024-07-31 22:42:19] GBT: SegWit is enabled [2024-07-31 22:42:22] getmininginfo: difficulty 9.0667e+013, networkhashps 6.2433e+020, blocks 854856 [2024-07-31 22:42:22] GBT new work received in 1424.86 ms

Every 5-10 second, the miner is asking for a new block template. You can also see it with --protocol-dump In the Bitcoin Core debug.log you find this: 2024-07-31T20:41:05Z CreateNewBlock(): block weight: 496559 txs: 161 fees: 586650 sigops 904 2024-07-31T20:41:11Z CreateNewBlock(): block weight: 496370 txs: 300 fees: 592185 sigops 1065 2024-07-31T20:41:17Z CreateNewBlock(): block weight: 496323 txs: 287 fees: 633692 sigops 1108 2024-07-31T20:41:23Z CreateNewBlock(): block weight: 496450 txs: 270 fees: 705179 sigops 1203 2024-07-31T20:41:34Z CreateNewBlock(): block weight: 496674 txs: 392 fees: 770463 sigops 1361 2024-07-31T20:41:40Z CreateNewBlock(): block weight: 496666 txs: 384 fees: 782454 sigops 1361 2024-07-31T20:41:46Z CreateNewBlock(): block weight: 496402 txs: 458 fees: 803908 sigops 1731 2024-07-31T20:41:52Z CreateNewBlock(): block weight: 496459 txs: 451 fees: 812029 sigops 1753 2024-07-31T20:42:06Z CreateNewBlock(): block weight: 496422 txs: 334 fees: 847471 sigops 1732 2024-07-31T20:42:19Z CreateNewBlock(): block weight: 496814 txs: 416 fees: 889402 sigops 2029

A new block is created and sent back to the miner. Every 5-10 sec....

I donno what the miner is working on, there is no "feedback" in the console. If the miner ignores the new work or takes the new work it receives.

The reason I'm asking about the hash/sec, is that my PC is hashing with 14 M hash/sec, but I donno what it's hashing. If one nonce is one hash, than in 5 sec I can hash 70.000.000 nonce? The nonce goes to 4.294.967.295 (FFFF FFFF). So if the miner asks for a new work, it never finishes the first work. That would be 1,6% ? I donno how to calculate this

No Feedback like : [TIME] Finished hashing block AAA : from 0 to FFFF FFFF [TIME] New work BBB : block weight: 496814 txs: 416 fees: 889402 something....

Block "Weight 3,993,216 WU" https://www.blockchain.com/explorer/blocks/btc/854856 PS: Look at the nonce too "Nonce 69,370,386", I could have made it !!! :)))

Jul 31 '24 23:07 scorpim

BTW: https://www.blockchain.com/explorer/assets/bch

Quote

Bitcoin Cash can support 25,000 transactions per block compared with Bitcoin’s 1,000 to 1,500 per block. Additionally, as of March 2022, the maximum block size for BCH was increased fourfold to 32 MB.

Jul 31 '24 23:07 scorpim

1 hash = one nonce. If you want more feedback you can add --hash-meter. You can also check CPU utilization to confirm it's working. The hash rate is normally only reported when there some other useful information to display. A heartbeat log is just a waste of time and affects performance.

"currentblockweight" is in the GBT reply and might be of use if it can be taken at face value and is provided by all coins but I can't find any specification for it. FYI the problem seems to be in the size calculation in util.c:all_data_cb.

Edit: Ignore the preceding, the log editing confused me. Please post the full logs with debug and protocol dump, from the start until a crash or the first New Block log so I can do a side by side comparison.

Aug 01 '24 00:08 JayDDee

Thanks for the info (nonce = hash)

I have to get back to you, about the logs later. I'm doing some serious tests. You will like the result !!!

About the crash I can tell you, what I found so far ::: Printed the command output result directly into a file instead > crash.txt !!! The miner did NOT crashed !!! It seems that it only crashes in the command window.

But, every 10 sec the miner is requesting a new block and gets it. 4 MB large files (blocks). That's too much. Lot of calculations and network traffic. 1 minute 6 * 4 MB = 24 MB 10 min = 240 MB

I'll get back with some other interesting results too and details/logs (and ideas) and summarizing ;) Hold on to your panties...

Aug 01 '24 19:08 scorpim

If the dos window closes it means cpuminer exited. If it didn't crash there should be an error log. You can add a pause in the bat file to keep the window open.

Aug 01 '24 23:08 JayDDee

Lets focus on the issue. If I understand correctly it works with the default max weight as long as you don't use --protocol-dump option. The only thing left to test is submitting a block and that's less likely than winning the lottery.

The crash with protocol dump appears to be when trying to print the protocol log for the GBT response. It prints the timestamp and crashes. The code looks pretty benign, just calls to library functions:

if (opt_protocol) { char *s = json_dumps(val, JSON_INDENT(3)); applog(LOG_DEBUG, "JSON protocol response:\n%s", s); free(s); }

Maybe the string was too long for printf, could be a stack overflow. It would take some low level debugging to figure out what's going on. I don't recommend reducing the max weight to make protocol dump work.

With the central issue understood everything else is irrelevant.

Aug 03 '24 03:08 JayDDee

A few clarifications about some misunderstandings. Job/work is what you get from a GBT request, it contains the blockheader which you hash. Jobs don't end, they get replaced with new jobs, You're misreading the hash rate, ignore the first reports it takes a while to get a proper hashrate report. Consult the wiki to understand logs.

Aug 03 '24 18:08 JayDDee

Yes, the miner works ok, as long as you dont use --protocol-dump. printf might be the issue. It you want to actually debug, ONLY then you have to reduce the block size to 500 K to be printed in the console.

AND: If you print it to a file "miner < file.txt", NO need to reduce the block size. That works to. printf have to print a looong text. 4 MB large. You could see that in the debug file I uploaded to you. 4 blocks = 17 MB BUT if printf fails in the console window, why it's working when printing it into a file? Might be also a console issue. I donno...

Protocol dump is ok, it just might be too much to print, that you can't/want read anyway :) Maybe to print the response of that 4 MB into the console is not necessary. Maybe like this: --protocol-dump noblock

if (opt_protocol and not 'noblock' ) { print it }

I think you can ignore this "issue" for now. Not many is using protocol dump, just add "noblock". If someone complains, tell to use "noblock". OR !!! by default use noblock, if they want the block JSON too, add it: --protocol-dump withblock

     You:"It would take some low level debugging to figure out what's going on."

Problem solved :) No need to complicate this, keep it simple :)

Yes, the work/jobs are replaced. Every 5 second? :) This is what I dont understand, how this works. My CPU is NOT that fast. Thats why I was asking if there is a way to see it: [TIME] New Work ID abcd [TIME] Work ID abcd is finished in mm:ss with x hash/sec

I have tested pooler's on my old PC for one day. I have 2. My old PC has my web server, mysql, bitcoin core etc. I'm using my other PC with Intel i5 3.3 GHz, to connect to the old one. So I was thinking to test my old PC with CPU miner (first). After all, it's already up and running 24/7

It actually works, you just need some luck. See the result bellow. minerd --debug < file.txt To bad that you have to use --debug or you miss this: DEBUG: hash > target (false positive)

These kind of feedback would be good to have. minerd is geting a new block every 5 sec too? Is this new block replacing the one that it's working on? Or the miner finishes the work first and ignores the new block? Then why ask for one new and downloading it? opti does the same... This is why I'm asking for a feedback [TIME] Bla, bla, bla. What are they working on actually? :)

PS: I'll wait an hour to see the average hash rate.

This dump gives you some hope, that CPU mining is not impossible, it's just difficult :)))

DEBUG DUMP

[2024-08-04 20:01:53] thread 0: 5738532 hashes, 3006 khash/s [2024-08-04 20:01:53] thread 1: 3053220 hashes, 3069 khash/s [2024-08-04 20:01:54] DEBUG: got new work in 1007 ms [2024-08-04 20:01:58] thread 0: 15030276 hashes, 3069 khash/s [2024-08-04 20:01:59] thread 1: 15343048 hashes, 3070 khash/s [2024-08-04 20:01:59] thread 0: 3069288 hashes, 3177 khash/s [2024-08-04 20:02:00] DEBUG: got new work in 1006 ms [2024-08-04 20:02:04] DEBUG: hash > target (false positive) Hash: 00000000fd74969eaf51bbd1f2afcfecf917149f19d09b2965b66bbc41d4d301 Target: 000000000000000000031abe0000000000000000000000000000000000000000 [2024-08-04 20:02:05] thread 1: 15352288 hashes, 2972 khash/s [2024-08-04 20:02:05] thread 0: 15886816 hashes, 2941 khash/s [2024-08-04 20:02:06] DEBUG: got new work in 1010 ms [2024-08-04 20:02:14] thread 0: 14707300 hashes, 1876 khash/s [2024-08-04 20:02:14] thread 1: 14861864 hashes, 1837 khash/s [2024-08-04 20:02:15] DEBUG: got new work in 1004 ms

[2024-08-04 20:23:04] thread 0: 15941020 hashes, 1996 khash/s [2024-08-04 20:23:05] DEBUG: got new work in 1007 ms [2024-08-04 20:23:08] thread 0: 9980612 hashes, 3133 khash/s [2024-08-04 20:23:08] thread 1: 10191656 hashes, 3107 khash/s [2024-08-04 20:23:10] thread 1: 6214432 hashes, 2904 khash/s [2024-08-04 20:23:10] thread 0: 6265320 hashes, 2732 khash/s [2024-08-04 20:23:11] DEBUG: got new work in 1008 ms [2024-08-04 20:23:13] DEBUG: hash > target (false positive) Hash: 00000000c60b6b7591dd73b597d9fcd21f2d3cc072e48fcc74e48825226e47d6 Target: 000000000000000000031abe0000000000000000000000000000000000000000 [2024-08-04 20:23:16] thread 0: 13661884 hashes, 3169 khash/s [2024-08-04 20:23:16] thread 1: 14519772 hashes, 3152 khash/s [2024-08-04 20:23:17] DEBUG: got new work in 1011 ms [2024-08-04 20:23:23] thread 1: 15758412 hashes, 2414 khash/s

[2024-08-04 20:46:00] DEBUG: got new work in 1004 ms [2024-08-04 20:46:03] thread 0: 9801516 hashes, 3147 khash/s [2024-08-04 20:46:03] thread 1: 9913256 hashes, 3163 khash/s [2024-08-04 20:46:05] thread 0: 6293112 hashes, 3167 khash/s [2024-08-04 20:46:05] thread 1: 6326280 hashes, 3179 khash/s [2024-08-04 20:46:06] DEBUG: got new work in 1010 ms [2024-08-04 20:46:11] thread 1: 15895176 hashes, 3154 khash/s [2024-08-04 20:46:11] thread 0: 15835768 hashes, 3131 khash/s [2024-08-04 20:46:12] DEBUG: got new work in 1007 ms [2024-08-04 20:46:17] thread 0: 15657272 hashes, 3054 khash/s [2024-08-04 20:46:17] thread 1: 15769064 hashes, 2988 khash/s [2024-08-04 20:46:18] DEBUG: got new work in 1016 ms [2024-08-04 20:46:24] DEBUG: hash > target (false positive) Hash: 00000000386cacea79a44d53adf975b41ef0c0142720519f78ea5ef4a9cdee26 Target: 000000000000000000031abe0000000000000000000000000000000000000000 [2024-08-04 20:46:26] thread 0: 15272428 hashes, 2114 khash/s [2024-08-04 20:46:26] thread 1: 14938488 hashes, 2056 khash/s [2024-08-04 20:46:27] DEBUG: got new work in 1011 ms [2024-08-04 20:46:30] thread 1: 10281136 hashes, 2988 khash/s [2024-08-04 20:46:30] thread 0: 10570632 hashes, 3030 khash/s [2024-08-04 20:46:32] thread 1: 5975688 hashes, 3119 khash/s

Aug 04 '24 21:08 scorpim

Stratum mining pushes a new job but solo ming doesn't so the miner has to poll the server regularly to make sure it has the latest. You can adjust the time using --scantime, default is 5 seconds. False positives are an issue with how Pooler tests hash and only of interest to him, that's why it's display is debug only.

That was a good observation that the crash only occurs on console output but not file output. It looks like it's the DOS shell that's crashing. Based on that the issue can be closed.

Aug 04 '24 22:08 JayDDee

Sorry for the late reply. It's like 3 am again :( Family life, you know...

DOS problem is no problem, ignore it.

But the 5 sec interval is a problem. Is the current job replaced with a new one every 5 sec? I dont see any feedback on that. I did tried --scantime. Both with poolers and opti. You have to experiment with it to figure out how long it takes from 0 to max. With poolers I can see that it takes 199 sec. (3:19 minutes) To figure it out, you have to use a large scantime, like 600. When the job is done, the miner gets a new work. Thats good news. The problem is that there is no "getmininginfo". So, when a new block turns up, you miss it. With opti, there is no feedback, so it's difficult to know how long it takes. Based on hash calculation 325 sec (5:25 minute)

I write down below the result how it looks like. With opti, you get every 5 minutes "Periodic Report" and only then it gets a new work. So it doesnt matter how large you set the scantime. With opti I did not used "--no-longpoll"

YOU : Stratum mining pushes a new job but solo ming doesn't so the miner has to poll the server regularly to make sure it has the latest.

Regardless of what, if you use --no-longpoll, the miner should do a "getmininginfo" (only). every 5 sec maybe? :) So --no-longpoll, could be used for solo mining. You can be delayed dramatically other wise. ( not that it matter, no jackpot, but... )

Or plan B. The miner monitors manually the network and when a new block turn up, he hits the [CTRL]+C, and restarting the miner :)))

BTW: no matter witch oti program you use it always says - "Enabled optimizations: SSE2" Strange, I use the avx version...

==========================================

minerd, SSE2 or what? No feedback... --debug --no-longpoll --scantime 600 [2024-08-07 02:26:08] 4 miner threads started, using 'sha256d' algorithm. [2024-08-07 02:26:08] Binding thread 1 to cpu 1 [2024-08-07 02:26:08] Binding thread 3 to cpu 3 [2024-08-07 02:26:08] Binding thread 0 to cpu 0 [2024-08-07 02:26:08] Binding thread 2 to cpu 2 [2024-08-07 02:26:08] DEBUG: got new work in 203 ms [2024-08-07 02:26:08] thread 0: 2097152 hashes, 5369 khash/s [2024-08-07 02:26:08] thread 1: 2097152 hashes, 5369 khash/s [2024-08-07 02:26:08] thread 3: 2097152 hashes, 5369 khash/s [2024-08-07 02:26:08] thread 2: 2097152 hashes, 5369 khash/s [2024-08-07 02:26:13] DEBUG: hash > target (false positive) Hash: 00000000adb9291da4be6d064b19de543f060faaefd0e5b5b18fc7688586f467 Target: 000000000000000000031abe0000000000000000000000000000000000000000 [2024-08-07 02:29:25] thread 3: 1071644640 hashes, 5450 khash/s <- The combined hash tells it came to the end [2024-08-07 02:29:25] thread 0: 1071644640 hashes, 5449 khash/s [2024-08-07 02:29:25] thread 2: 1071644640 hashes, 5450 khash/s [2024-08-07 02:29:25] thread 1: 1071644640 hashes, 5446 khash/s [2024-08-07 02:29:25] DEBUG: got new work in 203 ms <- getting a new work

======================================================

cpuminer-avx --debug --hash-meter --scantime 600

[2024-08-07 19:27:24] Enabled optimizations: SSE2 [2024-08-07 19:27:24] Coinbase address uses B58 coding [2024-08-07 19:27:24] CPU affinity [!!!!] [2024-08-07 19:27:24] 4 of 4 miner threads started using 'sha256d' algorithm [2024-08-07 19:27:24] Default miner thread priority 0 (nice 19) [2024-08-07 19:27:24] Binding thread 0 to cpu 0 [2024-08-07 19:27:24] Binding thread 2 to cpu 2 [2024-08-07 19:27:24] Binding thread 1 to cpu 1 [2024-08-07 19:27:24] Binding thread 3 to cpu 3 [2024-08-07 19:27:24] GBT: SegWit is enabled [2024-08-07 19:27:24] getmininginfo: difficulty 9.0667e+013, networkhashps 5.2844e+020, blocks 855793 [2024-08-07 19:27:24] GBT new work received in 15.62 ms [2024-08-07 19:27:24] New Block 855794, Tx 7, Net Diff 9.0668e+013, Ntime 7eaeb366 Miner TTF @ 80.00 h/s 0m00s, Net TTF @ 528.44 Eh/s 12m16s [2024-08-07 19:27:24] Threads restarted for new work. [2024-08-07 19:27:24] Thread 0, CPU 0: 20.00 h/s [2024-08-07 19:27:24] Thread 0, CPU 0: 20.00 h/s [2024-08-07 19:27:24] Thread 1, CPU 1: 20.00 h/s [2024-08-07 19:27:24] Thread 0, CPU 0: 20.00 h/s [2024-08-07 19:27:24] Thread 2, CPU 2: 20.00 h/s [2024-08-07 19:27:24] Thread 1, CPU 1: 20.00 h/s [2024-08-07 19:27:24] Thread 0, CPU 0: 20.00 h/s [2024-08-07 19:27:24] Thread 2, CPU 2: 20.00 h/s [2024-08-07 19:27:24] Thread 1, CPU 1: 20.00 h/s [2024-08-07 19:27:24] Thread 3, CPU 3: 767.79 kh/s [2024-08-07 19:27:24] Thread 2, CPU 2: 767.79 kh/s [2024-08-07 19:27:24] Thread 1, CPU 1: 20.00 h/s [2024-08-07 19:27:24] Thread 0, CPU 0: 767.79 kh/s [2024-08-07 19:27:24] Thread 1, CPU 1: 20.00 h/s [2024-08-07 19:27:24] Thread 1, CPU 1: 20.00 h/s [2024-08-07 19:27:24] Thread 1, CPU 1: 767.79 kh/s [2024-08-07 19:29:44] Thread 2, CPU 2: 3303.56 kh/s [2024-08-07 19:29:44] Thread 3, CPU 3: 3303.56 kh/s [2024-08-07 19:29:45] Thread 1, CPU 1: 3281.87 kh/s [2024-08-07 19:29:46] Thread 0, CPU 0: 3254.70 kh/s [2024-08-07 19:32:49] Thread 2, CPU 2: 3305.70 kh/s [2024-08-07 19:32:49] Thread 2, CPU 2: 3305.70 kh/s [2024-08-07 19:32:49] GBT: SegWit is enabled [2024-08-07 19:32:49] getmininginfo: difficulty 9.0667e+013, networkhashps 5.2712e+020, blocks 855794 [2024-08-07 19:32:49] sha256d: http://10.0.0.2:8332 Periodic Report 5m24s 5m24s Share rate 0.00/min 0.00/min Hash rate 0.00h/s 0.00h/s (7579.57kh/s) Submitted 0 0 Accepted 0 0 0.0% Hi/Lo Share Diff 0 / 9e+099 [2024-08-07 19:32:49] GBT new work received in 15.63 ms [2024-08-07 19:32:49] New Block 855795, Tx 10, Net Diff 9.0668e+013, Ntime c3afb366 Miner TTF @ 13.15 Mh/s 73y73d, Net TTF @ 527.12 Eh/s 12m18s [2024-08-07 19:32:49] Threads restarted for new work. [2024-08-07 19:32:49] Thread 3, CPU 3: 3303.75 kh/s [2024-08-07 19:32:49] Thread 1, CPU 1: 3277.44 kh/s [2024-08-07 19:32:49] Thread 0, CPU 0: 3262.73 kh/s [2024-08-07 19:38:14] Thread 3, CPU 3: 3305.69 kh/s [2024-08-07 19:38:14] Thread 3, CPU 3: 3305.69 kh/s [2024-08-07 19:38:14] GBT: SegWit is enabled [2024-08-07 19:38:14] getmininginfo: difficulty 9.0667e+013, networkhashps 5.2712e+020, blocks 855794 [2024-08-07 19:38:14] sha256d: http://10.0.0.2:8332 Periodic Report 5m24s 10m49s Share rate 0.00/min 0.00/min Hash rate 0.00h/s 0.00h/s (8236.20kh/s) Submitted 0 0 Accepted 0 0 0.0% Hi/Lo Share Diff 0 / 9e+099 [2024-08-07 19:38:14] GBT new work received in 0.00 ms [2024-08-07 19:38:15] Thread 2, CPU 2: 3298.86 kh/s [2024-08-07 19:38:16] Thread 1, CPU 1: 3287.34 kh/s [2024-08-07 19:38:18] Thread 0, CPU 0: 3262.53 kh/s [2024-08-07 19:43:40] Thread 3, CPU 3: 3298.39 kh/s [2024-08-07 19:43:40] Thread 3, CPU 3: 3298.39 kh/s [2024-08-07 19:43:40] GBT: SegWit is enabled [2024-08-07 19:43:40] getmininginfo: difficulty 9.0667e+013, networkhashps 5.3246e+020, blocks 855795 [2024-08-07 19:43:40] sha256d: http://10.0.0.2:8332 Periodic Report 5m25s 16m15s Share rate 0.00/min 0.00/min Hash rate 0.00h/s 0.00h/s (9887.45kh/s) Submitted 0 0 Accepted 0 0 0.0% Hi/Lo Share Diff 0 / 9e+099 [2024-08-07 19:43:40] GBT new work received in 15.63 ms [2024-08-07 19:43:40] New Block 855796, Tx 11, Net Diff 9.0668e+013, Ntime 4db2b366 Miner TTF @ 13.15 Mh/s 37y37d, Net TTF @ 532.46 Eh/s 12m11s [2024-08-07 19:43:40] Threads restarted for new work. [2024-08-07 19:43:40] Thread 0, CPU 0: 3258.91 kh/s [2024-08-07 19:43:40] Thread 1, CPU 1: 3277.47 kh/s [2024-08-07 19:43:40] Thread 2, CPU 2: 3293.65 kh/s

Aug 08 '24 01:08 scorpim

I'm not going to respond to every little thing you don't understand. There is a minor issue with logging interim work which is already being addressed, but the mining is working correctly.

Aug 08 '24 02:08 JayDDee

No problem. I was thinking to check this with "mingw_w64". I have never used it. Don't even know where to start. Never mind. I think its time to experiment a little, figure things out. Fixing solo etc (in due time). We did learned a lot whats working, how and whats not. Till then, thanks for all the infos :)

Aug 09 '24 01:08 scorpim

Solo isn't broken, it's just a logging issue.

Aug 09 '24 01:08 JayDDee

That is good to know. Thank you!

Aug 11 '24 00:08 scorpim

I'm preparing a new release soon and I have a few more notes about GBT scan time.

The visible change is a New Work log every time new work is fetched using GBT, it's already the case for stratum.

The default scan time was reduced from 10s to 5s for a specific coin that had a very short block time. So short that blocks could be missed altogether. In fact 2 blocks could have the same ntime. This was an extreme case at the other end of the spectrum from BTC. Since BTC is not the target market for cpuminer I'm hesitant to make any changes that favour BTC.

Another factor is that processing BTC work is very expensive due to the high number of transactions.The typical CPU friendly coin has few transactions per block. It is wise not to fetch BTC too frequently.

The historical default scan time of 10s for BTC is 1/60 the 10m block time. That seems to be a reasonable frequency and I recommend that frequency for any coin, adjusting the scan time based on expected network block time.

A final note about BTC is the hashrate is so high that many higher end CPUs, particularly with SHA or AVX512, can exhaust the 32 bit nonce range (4Ghash) in less than 10 seconds so new work is fetched before the recommended scan time expires.

Scan time option only affects GBT, stratum pushes data and doesn't need to be polled. Stratum also uses extranonce2 to handle nonce exhaust between jobs for high hashrate algos.

I'll close this issue when the new version is released.

Aug 24 '24 02:08 JayDDee

Bitcoin Core - RPC connection

DEBUG DUMP