Pool setup issue with stratum server response to miner about pool HOT 17 CLOSED

Sorry to hear about the trouble. We'll get this taken a look at.

from pool.

Are you using CPUMiner from https://github.com/lbryio/cpuminer ?

And have you read this https://github.com/lbryio/lbrycrd/tree/master/contrib/mining ?

from pool.

Answer is no, and no.
I'll give it a try right away, thanks

from pool.

Very nice tutorial, thanks. I used docker containers to see if I have better luck.

I ran latest lbrycrd with:

lbrycrdd -rpcuser=XXX -rpcpassword=YYY -rpcport=20001 -deprecatedrpc=validateaddress -deprecatedrpc=accounts -reindex

Updated to MYSQL database, and ran (pruvot) cpuminer (with lbry support) :

./cpuminer -a lbry -o stratum+tcp://127.0.0.1:3334/ -D -u bWAXf68iah2JBrtM98He6Cjw6CKCnRJJbJ -p tu8tu5 -t 1

And all I got was :

[2020-05-07 04:59:52] Stratum session id: 360db6796ac496bd58c67e093a4ddf46
[2020-05-07 04:59:53] Stratum authentication failed
[2020-05-07 04:59:53] ...retry after 10 seconds

This is what a network snooping of stratum exchange shows:

{"id": 2, "method": "mining.authorize", "params": ["bWAXf68iah2JBrtM98He6Cjw6CKCnRJJbJ", "tu8tu5"]}
{"id":2,"result":false,"error":null}

This address comes from:

lbrycrd-cli [...] getnewaddress
bWAXf68iah2JBrtM98He6Cjw6CKCnRJJbJ

And this is what stratum says:

09:05:39: 2020-05-07 starting stratum for lbry on 127.0.0.1:3334
09:05:39: connecting to coind LBC
09:05:39: ERROR getaccountaddress Local LBRY Instance
09:05:40: Local LBRY Instance error getblocktemplate result
2020-05-07 09:05:40 [X.Y.Z.T] bWAXf68iah2JBrtM98He6Cjw6CKCnRJJbJ, lbry, bad mining address bWAXf68iah2JBrtM98He6Cjw6CKCnRJJbJ

Maybe related to segwit think with getblocktemplate ?

lbrycrd-cli [...] getblocktemplate
error code: -8
error message:
Segwit support is now required. Please include "segwit" in the client's rules.

Could you help please ? (what is passwd "tu8tu5" all about anyway?)

Thanks

EDIT#1:
I think the line

insert into coins(name, symbol, symbol2, algo, enable, auto_ready, rpcuser, rpcpasswd, rpchost, rpcport, rpccurl, rpcencoding, hasgetinfo, hassubmitblock, usememorypool, usesegwit, auxpow) 
  values('Local LBRY Instance', 'LBC', 'LBC', 'lbry', 1, 1, 'ruser', 'rpswd', '127.0.0.1', 19245, 1, 'utf-8', 0, 1, 0, 0, 0);

Is wrong, becaue segwit has to be = 1. Right?

EDIT#2:
got rid of the "getblocktemplate" error by modifying rpc_curl.cpp of stratum and getting rid of this :

	//headers = curl_slist_append(headers, "Content-Type: application/json");

works like a charm. I found this by diff'ing between cli and stratum rpc calls, and tried everything.

EDIT#3:
cpuminer from pruvot still does a LOT of rejected shares so I had a look at CPUMiner from https://github.com/lbryio/cpuminer.
cpu-miner.cpp has an issue (I think) when running this part :

			while (time(NULL) >= g_work_time + 1)//20)
				sleep(1);

Because g_work_time is 0 (i added a printf to check), so... we're sleeping from 1/1/1970 until now+120 :)

from pool.

Yes, do set the useSegwit to 1. Segwit requirements enabled after that documentation was made.

You ran "-reindex" once after upgrading to current code? You shouldn't and definitely don't want that every time. And getblocktemplate probably won't work until that finishes (er, you're caught up to current).

The "tu8tu5" is the yiimp password. Yiimp has some settings dealing with that; it may not require one or may accept anything. I don't remember the default.

If you just want to mine with cpuminer you can connect it directly to lbrycrd. It doesn't require a pool.

from pool.

Thanks for your answer.
Yes I did a reindex, after a full sync with latest code. Still, the getblocktemplate issue in rpc_curl.cpp looks like a stratum server issue.

I know I don't require a pool for this setup, but all this is only a first test : having this to work [daemon with RPC <=> stratum server <=> any miner].

So, when I use tpruvot cpuminer (https://github.com/tpruvot/cpuminer-multi) => shares get rejected
when I use https://github.com/lbryio/cpuminer => it hashes, but nothing seems to be submitted :

[2020-05-07 16:10:24] 1 miner threads started, using 'lbry' algorithm.
[2020-05-07 16:10:27] thread 0: 2097152 hashes, 581.64 khash/s
[2020-05-07 16:11:27] thread 0: 34898470 hashes, 583.63 khash/s
[2020-05-07 16:12:27] thread 0: 35017569 hashes, 583.84 khash/s
[2020-05-07 16:13:27] thread 0: 35030323 hashes, 582.90 khash/s
[2020-05-07 16:14:27] thread 0: 34973937 hashes, 585.19 khash/s
[2020-05-07 16:15:27] thread 0: 35111537 hashes, 585.93 khash/s
[2020-05-07 16:16:27] thread 0: 35155898 hashes, 587.21 khash/s
[2020-05-07 16:17:27] thread 0: 35232725 hashes, 587.49 khash/s
[2020-05-07 16:18:27] thread 0: 35249319 hashes, 583.51 khash/s

Difficulty was set to 1 so it should at least send shares...

EDIT: I added the --stratum option to lbry cpuminer, but it segfaults at different places (lbryio/cpuminer#2). That's why I'd like to stick to cpuminer from tpruvot, and understand why I get all theses :

[2020-05-07 16:52:43] accepted: 0/13 (diff 0.008), 2302 kH/s booooo
[2020-05-07 16:52:43] reject reason: Invalid share
[2020-05-07 16:52:46] DEBUG: hash <= target
Hash:   00000069eeb0a65fcdc05808a766f7b1147ea8fd7cbebd70ede8fef8ab132a29
Target: 000000ffff000000000000000000000000000000000000000000000000000000
[2020-05-07 16:52:46] share diff 0.00944 (2.4x)
[2020-05-07 16:52:46] CPU #1: 574.58 kH/s
[2020-05-07 16:52:46] accepted: 0/14 (diff 0.009), 2303 kH/s booooo
[2020-05-07 16:52:46] reject reason: Invalid job id

If that helps, here the dumped traffic:

< 2020/05/08 12:30:27.156649  length=864 from=1205 to=2068
{"id":null,"method":"mining.notify","params":["14","b18ccdbb2880d9cd31d7d2a2665c68c42f272adc0376108ee5c2cd1864000c39","5530c251d2ed75b1cf22d724fc0719ed02e21a948d67060375478b81d7cc5435","01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff1803299d0b040289b55e08","7969696d70000000000001dedf27d2060000001976a91488ac00000000",["b106ad082a87e4c17848d6c216af0d2cb03c6dfd2be5ea4f11f01587c5667c35","76afa059916c420d9f465d5474a22ea9de5b9dcaf13970cd3458be2ce55f6045","0ba414e363c202730a0d175980018d5095804f5e9c9edd8e3523e739f6c49b84","9ced175b3dcbe96c62129393d5c7b141ff695554213cd70bd5affff579129857","91c2c94498b2a04b85cdba4e9d4d8b613754eea661dd2793a2503563428e6af5","165f9e7de30afb7455c28e5deb38bf13b2769fe7aa2fb34b8128918ff2d4e117","9aa4b9908a812c18206982b68a075cf3c3a3ab24d6189de6a19a167243777c09"],"20000000","1a01f02a","5eb58902",true]}
> 2020/05/08 12:30:44.654669  length=128 from=431 to=558
{"method": "mining.submit", "params": ["bH347ZT2dt1f7GU3N5xjBzANtsCoKBA6oE", "14", "00000000", "5eb58902", "d0269cc0"], "id":4}
< 2020/05/08 12:30:45.506852  length=58 from=2069 to=2126
{"id":4,"result":false,"error":[25,"Invalid share",null]}
> 2020/05/08 12:30:46.471219  length=128 from=559 to=686
{"method": "mining.submit", "params": ["bH347ZT2dt1f7GU3N5xjBzANtsCoKBA6oE", "14", "00000000", "5eb58902", "f68aab40"], "id":4}
< 2020/05/08 12:30:47.180344  length=58 from=2127 to=2184
{"id":4,"result":false,"error":[25,"Invalid share",null]}

EDIT :
https://github.com/ocminer/cpuminer-lbry => is working fine !

EDIT:
The "invalid share" pb is still a mystery to me.
The "invalid job id" comes from this problem in stratum code (rpc_curl.cpp):

bool opt_timeout = CURL_RPC_TIMEOUT; // 30sec

An int casted to a bool makes a 1sec timeout, which is sometimes not enough, even with a local daemon.

from pool.

I'm glad that ocminer/cpuminer-lbry is working for you.

Did you try lbryio/sgminer-gm ? I know that lbryio/sgminer-gm still has post-segwit bugs in it so it may not work either, but I also know that the stratum server obfuscates some of the segwit stuff so it may not matter.

You should also try lbryio/ccminer.

I compared the code in ocminer/cpuminer-lbry to the code in lbryio/cpuminer. They are very different. If they have the same heritage then it was eons ago. It appears that ocminer/cpuminer-lbry does not support any local access; it only works with a stratum server.

I have never tested the lbryio/cpuminer on a stratum server. I'm sad that it has bugs but it's not surprising. All the present lbry mining is done via the Baikal BK-B devices. None of the software miners have been well-maintained. For a similar reason in bitcoin land, none of the software miners have quality segwit support.

from pool.

The opt_timeout issue is a yiimp bug? In tpruvot/yiimp?

@bvbfan , are you interested in looking at any of the issues listed above?

from pool.

opt_timeout is a stratum (the C software from tptuvot) bug, IMO

from pool.

As a matter of fact, here is what I've achived :

• running a fully synched TESTNET node + stratum server + cpuminer-lbry. It worked fine (shares are accepted, and new blocks are mined on the test blockchain) (yay!)
• running a fully synched MAINNET node + (exact same) stratum server + some rented hashpower on miningrigsrental pointed at this stratum server. The shares are accepted by stratum server, but every block is rejected by daemon, nothing was mined.

Do you know how I could debug this problem ? Nothing strange in the daemon logs, how can I investigate this problem and maybe find the reason of this (costly!) fail.

Thanks again

from pool.

Add -D in command line arguments of cpuminer, since debug output is huge redirect it to file.

from pool.

Add -D in command line arguments of cpuminer, since debug output is huge redirect it to file.

Thanks. Unfortunately I don't use cpuminer, I rented hashpower from MRR. I was talking about the daemon. I used -debug=cmpctblock but seen nothing relevant.

from pool.

Using Testnet isn't very helpful unless you actually add some claims to the blocks you are mining. Mining empty blocks is easier than mining non-empty blocks, from a generate-a-valid-block standpoint, and mining blocks with segwit transactions is even more difficult.

from pool.

Hi BrannonKing, thanks for your reply.
Can you elaborate on that ?

My problem is that I setup a stratum server (stratum C program), pointed it to my lbry daemon on MAINNET, then rented some hashpower on miningrigrental. Shares are accepted by stratum server, communication (getblocktemplate) works fine, but 100% of blocks get rejected by lbry daemon instance.

In my understanding, it should just work : blocks should be successfully mined, and daemon should be rewarded with block reward, no ? (FYI i rented about 10 TH/s for 3 hours).

Or maybe should I file a separate issue on this ?

from pool.

Are your blocks being rejected on mainnet for a lack of sufficient work? If so, then that is the expected result. The stratum servers tell their miners a lower work requirement than the real block requirement, because it uses the incoming blocks to determine the hash rate of the individual miners, so that it can distribute the reward according to the amount of work done by each miner in the pool. In other words, you need to mine longer or with a higher hash rate to actually succeed at mining a block.

from pool.

Thanks for your answer. Yes, I am well aware of that (difference between stratum proxy difficulty and real network difficulty). But 3 hours with 10 TH/s on a ~100 TH/s, I should have mined 1/10th of blocks (not none), am I correct here ? That's why I think that something's not right.

This is output of stratum server during this test (actual dates & block numbers) :

2020-05-15 09:09:42: REJECTED LBC block 764673
2020-05-15 10:11:22: REJECTED LBC block 764693
2020-05-15 10:27:16: REJECTED LBC block 764700
2020-05-15 10:46:43: REJECTED LBC block 764707
2020-05-15 10:49:42: REJECTED LBC block 764707
2020-05-15 10:50:46: REJECTED LBC block 764707
2020-05-15 10:53:18: REJECTED LBC block 764707
2020-05-15 11:10:32: REJECTED LBC block 764717
2020-05-15 11:18:55: REJECTED LBC block 764720

So this log means that hash was acceptable in terms of current network difficulty (very roughly about 1/10 blocks which is quite logical, then it was submitted to the daemon, but it was rejected by the daemon.

My question is : how to debug this ? If someone has a (couple TH/s) LBRY algo rig, maybe we can make a test or something (I can pay of course : for example I pay for one block in advance, then we mine until we find a block).

from pool.

lbrycrd should write the reasons for its rejection to its log. It also often returns text about why it failed from the submitblock call. Maybe you could make the stratum server print out the text that comes back from submitblock?

from pool.