CKPOOL - Open source pool/proxy/passthrough/redirector/library in c for Linux

[-ck]

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.

Code:

		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.

[ProfMac]

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.

Code:

		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.

[chillfactr]

Ok fiured it out

[chillfactr]

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]

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]

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.

[peoples]

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

[-ck]

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

One workername can have 10 thousand separate workers all with the same workername, but each with separate diffs.

[peoples]

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

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]

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.

[peoples]

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   

[80sKid]

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]

/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.

[80sKid]

/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]

/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.

[80sKid]

Too funny. I thought I had installed the 64bit version.   Burning the new .iso now...

[jstnryan]

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

Code:

[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

Code:

{
"btcd" :  [
    {
        "url" : "192.168.1.14:18333",
        "auth" : "user",
        "pass" : "pass",
        "notify" : true
    }
],
"btcaddress" : "ADDRESS",
"serverurl" : [
    "192.168.1.23:3333"
]
}

log sample

Code:

[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

[o_solo_miner]

Code:

"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.

[jstnryan]

Code:

"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.”

[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