-ck (OP)
Legendary
Offline
Activity: 4214
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 30, 2018, 08:45:48 PM |
|
Offhand, do you know the oldest bitcoin version that is supported? I am looking at the code below, with a small modification that I made. if (sdiff >= diff) { if (new_share(sdata, hash, id)) { LOGINFO("Accepted client %s share diff %.1f/%.0f/%s: %s", client->identity, sdiff, diff, wdiffsuffix, hexhash); result = true; LOGDEBUG("stratifier.c Ln 6223 submitblock <hexstuff>"); // parse_upstream_block(ckp, val); } else {
Oh, and as for Bitbucket, it's just yet another login / password / interface to deal with. I'll deal with it. I don't know what bitcoin version, sorry. That is for a successful plain share, not a block solve! You don't need a login/pass etc. just to clone a repo, but whatever. github didn't offer what I wanted around the time I started working on ckpool.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
ProfMac
Legendary
Offline
Activity: 1246
Merit: 1002
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 10, 2018, 05:40:34 PM |
|
Old versions of the bitcoin daemon do not have the features required for ckpool to work completely, though I don't know how old you're talking about.
There's nothing in line 6225 that has anything to do with submitting a block? test_blocksolve goes to line 5949 which sends it to local_block_submit and in there line 2061 submits it to generator_submitblock and so on.
Bitbucket is the only authentic git repository for my source, so not sure why you need to look elsewhere?
Thanks for your reply. My current approach with bitcoin is to try to understand virtually every line of code on the version I started with, then move to the future. At the moment, I'm marooned pretty far in the past at 0.8.1. Real Soon Now I will leapfrog forward. Offhand, do you know the oldest bitcoin version that is supported? I am looking at the code below, with a small modification that I made. if (sdiff >= diff) { if (new_share(sdata, hash, id)) { LOGINFO("Accepted client %s share diff %.1f/%.0f/%s: %s", client->identity, sdiff, diff, wdiffsuffix, hexhash); result = true; LOGDEBUG("stratifier.c Ln 6223 submitblock <hexstuff>"); // parse_upstream_block(ckp, val); } else {
Oh, and as for Bitbucket, it's just yet another login / password / interface to deal with. I'll deal with it. Procedure diff_from_nbits in file libckpool.c clamps the minimum difficulty to approximately 256. I removed that code and it works correctly with a difficulty 1 network.
|
I try to be respectful and informed.
|
|
|
chillfactr
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 12, 2019, 11:36:59 PM Last edit: January 17, 2019, 04:31:25 AM by chillfactr |
|
Ok fiured it out
|
|
|
|
chillfactr
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 17, 2019, 04:32:46 AM |
|
I was testing the latest code in proxy mode which starts up fine and works with my antminers no problem.
[root@localhost ck]# bin/ckpool -Ap -c etc/ckproxy.conf [2018-09-13 21:37:44.404] ckproxy generator starting [2018-09-13 21:37:44.404] ckproxy stratifier starting [2018-09-13 21:37:44.404] ckproxy connector starting [2018-09-13 21:37:44.407] ckproxy connector ready [2018-09-13 21:37:44.408] Loaded 2 users and 0 workers [2018-09-13 21:37:44.408] ckproxy stratifier ready [2018-09-13 21:37:50.800] Proxy 0:stratum+tcp://us-east.stratum.slushpool.com:3333 connection established [2018-09-13 21:37:51.415] Successfully connected to pool 0 stratum+tcp://us-east.stratum.slushpool.com:3333 as proxy [2018-09-13 21:37:51.415] ckproxy generator ready
However, I get the following when a Halong T1 tries to connect to the proxy:
[2018-09-13 21:38:06.435] Temporarily insufficient proxies to accept more clients [2018-09-13 21:38:06.435] Failed to provide subscription due to no sdata
The T1 will connect directly to slush pool without a problem.
Did you figure it out? to get connected?
|
|
|
|
peoples
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 82
Merit: 11
|
Hey -ck
thanks for your work and sharing of this great piece of pool software.
I played around with your ckpool to learn and better understand mining process.
Now one question (so far) comes up, why does the pool re-adjust the vardiff from scratch for every known client after reconnects / instance takeover (with your -H option) / ... Doesn't it put alot of stress on a pool server with thousands of clients connected if , for example , you make a instance takeover and all thousand clients start to re-djust vardiff with x shares per second ? Since you already have per worker information stored, isn't it better to store also last vardiff information and start from there on the next connection of the same worker ?
Thanks
|
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4214
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 13, 2019, 09:13:53 AM |
|
Hey -ck
thanks for your work and sharing of this great piece of pool software.
I played around with your ckpool to learn and better understand mining process.
Now one question (so far) comes up, why does the pool re-adjust the vardiff from scratch for every known client after reconnects / instance takeover (with your -H option) / ... Doesn't it put alot of stress on a pool server with thousands of clients connected if , for example , you make a instance takeover and all thousand clients start to re-djust vardiff with x shares per second ? Since you already have per worker information stored, isn't it better to store also last vardiff information and start from there on the next connection of the same worker ?
Thanks
That's a lot of data to hand over, the handover only hands over sockets, not the state of vardiff etc., and all of them will have to reconnect so all the previous connections will be invalid so you won't know who's on which socket after reconnect anyway. Worker names does not equal which socket they're connected to.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
peoples
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 82
Merit: 11
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 13, 2019, 11:05:16 AM |
|
Hey -ck
thanks for your work and sharing of this great piece of pool software.
I played around with your ckpool to learn and better understand mining process.
Now one question (so far) comes up, why does the pool re-adjust the vardiff from scratch for every known client after reconnects / instance takeover (with your -H option) / ... Doesn't it put alot of stress on a pool server with thousands of clients connected if , for example , you make a instance takeover and all thousand clients start to re-djust vardiff with x shares per second ? Since you already have per worker information stored, isn't it better to store also last vardiff information and start from there on the next connection of the same worker ?
Thanks
That's a lot of data to hand over, the handover only hands over sockets, not the state of vardiff etc., and all of them will have to reconnect so all the previous connections will be invalid so you won't know who's on which socket after reconnect anyway. Worker names does not equal which socket they're connected to. ok got it, thats for handover. But why not serving previous difficulty after reconnect ? Example: 1) Miner A with wokerName: MinerA connected and mined for a while on stable diff. 2) pool stores this diff information per worker 3) Miner A disconnects and reconnects after few minutes 4) pool identifies miner by workerName -> gets old diff value from log and serves the stored diff instead of starting new vardiff ramping ? Very likely that i oversee a detail, like i said -> Learning phase .. so thanks for your answers ![Wink](https://bitcointalk.org/Smileys/default/wink.gif)
|
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4214
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 13, 2019, 11:13:20 AM |
|
Hey -ck
thanks for your work and sharing of this great piece of pool software.
I played around with your ckpool to learn and better understand mining process.
Now one question (so far) comes up, why does the pool re-adjust the vardiff from scratch for every known client after reconnects / instance takeover (with your -H option) / ... Doesn't it put alot of stress on a pool server with thousands of clients connected if , for example , you make a instance takeover and all thousand clients start to re-djust vardiff with x shares per second ? Since you already have per worker information stored, isn't it better to store also last vardiff information and start from there on the next connection of the same worker ?
Thanks
That's a lot of data to hand over, the handover only hands over sockets, not the state of vardiff etc., and all of them will have to reconnect so all the previous connections will be invalid so you won't know who's on which socket after reconnect anyway. Worker names does not equal which socket they're connected to. ok got it, thats for handover. But why not serving previous difficulty after reconnect ? Example: 1) Miner A with wokerName: MinerA connected and mined for a while on stable diff. 2) pool stores this diff information per worker 3) Miner A disconnects and reconnects after few minutes 4) pool identifies miner by workerName -> gets old diff value from log and serves the stored diff instead of starting new vardiff ramping ? Very likely that i oversee a detail, like i said -> Learning phase .. so thanks for your answers ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) One workername can have 10 thousand separate workers all with the same workername, but each with separate diffs.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
peoples
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 82
Merit: 11
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 13, 2019, 11:32:25 AM |
|
Hey -ck
thanks for your work and sharing of this great piece of pool software.
I played around with your ckpool to learn and better understand mining process.
Now one question (so far) comes up, why does the pool re-adjust the vardiff from scratch for every known client after reconnects / instance takeover (with your -H option) / ... Doesn't it put alot of stress on a pool server with thousands of clients connected if , for example , you make a instance takeover and all thousand clients start to re-djust vardiff with x shares per second ? Since you already have per worker information stored, isn't it better to store also last vardiff information and start from there on the next connection of the same worker ?
Thanks
That's a lot of data to hand over, the handover only hands over sockets, not the state of vardiff etc., and all of them will have to reconnect so all the previous connections will be invalid so you won't know who's on which socket after reconnect anyway. Worker names does not equal which socket they're connected to. ok got it, thats for handover. But why not serving previous difficulty after reconnect ? Example: 1) Miner A with wokerName: MinerA connected and mined for a while on stable diff. 2) pool stores this diff information per worker 3) Miner A disconnects and reconnects after few minutes 4) pool identifies miner by workerName -> gets old diff value from log and serves the stored diff instead of starting new vardiff ramping ? Very likely that i oversee a detail, like i said -> Learning phase .. so thanks for your answers ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) One workername can have 10 thousand separate workers all with the same workername, but each with separate diffs. Amen ... of course makes sense, worker name is no unique identifier. Thanks for that. Does ckpool also adjusts diff down, or in general, is that something that pools do ? For example miner hashrate drops by 50% in a current session because a hasboard died.
|
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4214
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 13, 2019, 11:36:46 AM |
|
Does ckpool also adjusts diff down, or in general, is that something that pools do ? For example miner hashrate drops by 50% in a current session because a hasboard died.
Yes.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
peoples
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 82
Merit: 11
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 13, 2019, 12:48:29 PM |
|
Does ckpool also adjusts diff down, or in general, is that something that pools do ? For example miner hashrate drops by 50% in a current session because a hasboard died.
Yes. Great, thanks ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
80sKid
Newbie
Offline
Activity: 7
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 18, 2019, 01:48:29 AM |
|
Could use a little help please. I've been trying to compile/install ckpool, but it errors-out during 'make'. I have tried on two separate machines with the same results. Here's where it all ends: make[3]: Entering directory '/home/v3/ckpool/ckpool/src' CC libckpool.o CC sha2.o yasm -f x64 -f elf64 -X gnu -g dwarf2 -D LINUX -o sha256_code_release/sha256_sse4.A sha256_code_release/sha256_sse4.asm AR libckpool.a ar: `u' modifier ignored since `D' is the default (see `U') CC ckpool.o CC generator.o CC bitcoin.o CC stratifier.o stratifier.c: In function ‘read_poolstats’: stratifier.c:8512:17: warning: passing argument 1 of ‘json_get_int64’ from incompatible pointer type [-Wincompatible-pointer-types] json_get_int64(&last.tv_sec, val, "lastupdate"); ^ In file included from stratifier.c:23:0: ckpool.h:369:6: note: expected ‘int64_t * {aka long long int *}’ but argument is of type ‘__time_t * {aka long int *}’ bool json_get_int64(int64_t *store, const json_t *val, const char *res); ^~~~~~~~~~~~~~ CC connector.o CCLD ckpool /usr/bin/ld: i386:x86-64 architecture of input file `libckpool.a(sha256_sse4.A)' is incompatible with i386 output collect2: error: ld returned 1 exit status Makefile:502: recipe for target 'ckpool' failed make[3]: *** [ckpool] Error 1 make[3]: Leaving directory '/home/v3/ckpool/ckpool/src' Makefile:570: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory '/home/v3/ckpool/ckpool/src' Makefile:410: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/v3/ckpool/ckpool' Makefile:342: recipe for target 'all' failed make: *** [all] Error 2 Can anyone please tell me what steps I should take to get this to work? Both machines are Intel 64 bit with Debian. I'd be happy to donate some satoshi's for some help. Thank you. Oh, and I'm using the .zip file from: https://bitbucket.org/ckolivas/ckpool/get/5d4dbe166c31.zip
|
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4214
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 18, 2019, 01:50:36 AM |
|
/usr/bin/ld: i386:x86-64 architecture of input file `libckpool.a(sha256_sse4.A)' is incompatible with i386 output
Might be an intel 64 bit machine but it looks like you're trying to compile it for a 32 bit userspace. Ckpool is 64 bit only.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
80sKid
Newbie
Offline
Activity: 7
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 18, 2019, 01:55:45 AM |
|
/usr/bin/ld: i386:x86-64 architecture of input file `libckpool.a(sha256_sse4.A)' is incompatible with i386 output
Might be an intel 64 bit machine but it looks like you're trying to compile it for a 32 bit userspace. Ckpool is 64 bit only. I'm relatively new to Linux. Is there a way I can direct it to compile as 64 bit? I just assumed it would do that somehow on its own. By the way, I've been using your cgminer on another machine and it's been rock solid for a couple years. Nice work.
|
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4214
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 18, 2019, 01:56:55 AM |
|
/usr/bin/ld: i386:x86-64 architecture of input file `libckpool.a(sha256_sse4.A)' is incompatible with i386 output
Might be an intel 64 bit machine but it looks like you're trying to compile it for a 32 bit userspace. Ckpool is 64 bit only. I'm relatively new to Linux. Is there a way I can direct it to compile as 64 bit? I just assumed it would do that somehow on its own. By the way, I've been using your cgminer on another machine and it's been rock solid for a couple years. Nice work. It just means you've installed a 32 bit linux distribution. Make sure to use a 64 bit one. There is no reason to use 32 bit any more anywhere.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
80sKid
Newbie
Offline
Activity: 7
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 18, 2019, 02:31:11 AM |
|
Too funny. I thought I had installed the 64bit version. Burning the new .iso now...
|
|
|
|
jstnryan
Jr. Member
Offline
Activity: 61
Merit: 1
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 13, 2019, 07:47:24 AM |
|
It seems I have the pool compiled and running with remote node and block notify, however it rejects all shares, and continuously reconnects my test miner. Is there something obvious I missed? The below is using ckpool-splns, but the result is the same with ckpool. stdout [2019-07-13 07:12:13.289] ckpool generator starting [2019-07-13 07:12:13.293] ckpool stratifier starting [2019-07-13 07:12:13.294] ckpool connector starting [2019-07-13 07:12:13.294] ckpool connector ready [2019-07-13 07:12:13.344] ckpool generator ready [2019-07-13 07:12:13.344] Connected to bitcoind: 192.168.1.14:18333 [2019-07-13 07:12:13.364] ckpool stratifier ready [2019-07-13 07:32:22.491] | 0.00H/s 0.0 SPS 1 users 1 workers
ckpool.conf { "btcd" : [ { "url" : "192.168.1.14:18333", "auth" : "user", "pass" : "pass", "notify" : true } ], "btcaddress" : "ADDRESS", "serverurl" : [ "192.168.1.23:3333" ] }
log sample [2019-07-13 07:35:13.431] Pool:{"runtime": 1380, "lastupdate": 1563003313, "Users": 1, "Workers": 1, "Idle": 1, "Disconnected": 0} [2019-07-13 07:35:13.431] Pool:{"diff": "0.0", "accepted": 0, "rejected": 7405568, "lns": 0.1, "herp": 0.1, "reward": 0.390625} [2019-07-13 07:35:23.617] Client 7 rejecting for 120s, reconnecting [2019-07-13 07:35:23.623] Dropped client 7 192.168.1.52 user ADDRESS worker ADDRESS.worker [2019-07-13 07:35:23.629] Authorised client 8 worker ADDRESS.worker as user ADDRESS [2019-07-13 07:35:38.642] Stored local workbase with 3 transactions
|
cruzbit (https://cruzb.it) - Developer friendly ledger implementation. Play Hash Roulette (https://hashroulette.com)
|
|
|
o_solo_miner
Legendary
Offline
Activity: 2480
Merit: 1481
-> morgen, ist heute, schon gestern <-
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 14, 2019, 09:19:08 AM |
|
"btcaddress" : "ADDRESS", did you got an valid btc address in, or did you leave the ADDRESS ? It will only work with a proper btc address.
|
from the creator of CGMiner http://solo.ckpool.org for Solominers paused: passthrough for solo.ckpool.org => stratum+tcp://rfpool.org:3334
|
|
|
jstnryan
Jr. Member
Offline
Activity: 61
Merit: 1
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 14, 2019, 02:27:18 PM |
|
"btcaddress" : "ADDRESS", did you got an valid btc address in, or did you leave the ADDRESS ? It will only work with a proper btc address. Yes. And my test miner is obviously not configured as “ADDRESS.worker.”
|
cruzbit (https://cruzb.it) - Developer friendly ledger implementation. Play Hash Roulette (https://hashroulette.com)
|
|
|
o_solo_miner
Legendary
Offline
Activity: 2480
Merit: 1481
-> morgen, ist heute, schon gestern <-
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 14, 2019, 04:51:19 PM Last edit: July 18, 2019, 07:50:37 PM by o_solo_miner |
|
How does your testminer setup looks like? And what kind of miner did you use? As far as I can see, the pool works as normal. Only the tranfered shares of the miner get rejected, You may look deeper in the log files of ckpool for debug of the tranfered data from the miner to ckpool. Edit: Client 7 rejecting for 120s looks like the miner won't comunicate
|
from the creator of CGMiner http://solo.ckpool.org for Solominers paused: passthrough for solo.ckpool.org => stratum+tcp://rfpool.org:3334
|
|
|
|