[∞ YH] US/EU/AU solo.ckpool.org 2% fee solo mining 307 blocks solved!

[itrider]

Hi all,

Question about ckpool/Stratum difficulty changes. When I suggest a lower difficulty (e.g., from 512 down to 128), I observe a short window where ckpool still evaluates shares against the old diff and I get a burst of “Rejected … high diff” (sdiff < diff). Is this normal behavior tied to the new diff only taking effect on the next mining.notify (new job), or is there something I should tune on my side to avoid so many rejecteds during the transition?

Relevant excerpt:

[11:54:26.289] Upstream -> {"params":[512],"method":"mining.set_difficulty", ...}
[11:54:26.684] Sending upstream json: {"method":"mining.suggest_difficulty","params":[128], ...}
[11:54:26.694] Upstream -> {"params":[128],"method":"mining.set_difficulty", ...}

Right after that, I still see rejects logged versus 512:

[11:54:28.309] Rejected client ... high diff 133.9/512/147T: 0000000001e97314...
[11:54:28.430] Rejected client ... high diff 151.1/512/147T: 0000000001b1a949...
[11:54:28.749] Rejected client ... high diff 156.4/512/147T: 0000000001a316d5...

I do get accepts when sdiff > 512, which suggests old job still active:

[11:54:32.344] Accepted client ... share diff 780.5/512/147T: 000000000053f60f...

Then later, accepts show evaluation against 128 (as expected):

[11:55:04.695] Accepted client ... share diff 779.5/128/147T: 00000000005411b0...
[11:55:05.881] Accepted client ... share diff 128.2/128/147T: 0000000001ff47aa...

Is the spike in rejected shares during this handover considered normal, and is the recommended approach simply to wait for the next notify (or force a new job / reconnect) to minimize it? Any best practices to reduce rejecteds during diff transitions would be appreciated.

I'm not sure what mining software you're using but the same is true for CGMiner and for ESP-Miner/AXEOS used on BitAxe devices, normally I see a few rejected shares at the change of requested difficulty.

I don't think its an issue in the big scheme of things as it normally only lasts a few shares, the odds of you finding an above target share in that time are infinitesimally small.

Just file it under its not a problem and hash on!

Totally agree, during the handover you only lose low-quality shares, it’s brief, and it doesn’t happen often. The only annoyance on my side is that it artificially bumps ckpool’s rejected rate metric. From what I can tell, ckpool’s displayed reject rate tallies the sum of rejected vardiff, so when the transition happens on a miner sitting at a high vardiff, the indicator jumps even though nothing material is wrong.

Example from my logs (redacted), miner on high vardiff:
[2025-10-28 10:57:23.577] Rejected client ... high diff 361.8/21235/147T: 0000000000b52212...
[2025-10-28 10:57:23.679] Rejected client ... high diff 666.8/21235/147T: 0000000000624a2c...
[2025-10-28 10:57:23.784] Rejected client ... high diff 2635.0/21235/147T: 000000000018def8...
[2025-10-28 10:57:23.888] Rejected client ... high diff 200.1/21235/147T: 0000000001479548...

So yes, functionally not a problem, but the metric spikes when the vardiff is high during the switch, which can be misleading on dashboards.

Its a case of "doctor doctor it hurts when I do this", then don't do it.

Don't set or change the requested difficulty and let the pool decide based on your hash rate. Then you wont get any rejected shares other than stale or genuinely faulty shares.

AFAIK The pool code has good averaging and calculation to regulate the ideal difficulty for your miners anyway based on the submitted share rate, so if zero rejects is important to you let the pool worry about what share diff should be.

As for the stats, they are just indicators and really have zero impact on your ability to mine or submit a valid share.

Thanks for the suggestion. Just to clarify: I’m not manually setting vardiff. I let the pool handle difficulty based on share rate. What I’m seeing seems to come from the pool’s own adjustment logic around brief idle/reconnects, not from me forcing a diff.

Here’s a clean example that illustrates it:

[2025-10-31 09:19:25.156] Accepted client passthrough:1 subclient:16304 share diff 27153.7/21232/156T: 00000000000269da05f78f4166a9aa29c777b28793a371caf708ab784b97f6cc
[2025-10-31 09:19:25.156] Client passthrough:1 subclient:16304 biased dsps 60.27 dsps 60.27 drr 0.00 adjust diff from 21232 to: 201

Miner briefly disconnects/goes idle, dsps drops, and the pool decides to lower vardiff from 21232 to 201. After the miner comes back, it has adapted to diff 201, but the pool is still evaluating submitted shares against 21232 for a short window:

[2025-10-31 09:19:33.061] Rejected client passthrough:1 subclient:16304 high diff 491.8/21232/156T: 0000000000853ded4f5115985496eb55a91bcb49c372221dadd294d7e68512c7
[2025-10-31 09:19:33.066] Rejected client passthrough:1 subclient:16304 high diff 630.4/21232/156T: 000000000067f3cfce387abd9f6d9c6880a979d0a718607017cd684f8ef5d8c2
[2025-10-31 09:19:33.169] Rejected client passthrough:1 subclient:16304 high diff 725.5/21232/156T: 00000000005a53cd9334ff0718149e1d913df7f512b3a525b44fa72d0bb86dde

Functionally, I agree it’s minor: the rejects are low-value shares and the window is short. I only want to flag it for ck because it spikes the reported reject metric when it happens on a high-vardiff miner, even though nothing is actually wrong.

If this is intended (new diff applies on next notify/job only) then all good; if not, perhaps forcing an immediate notify when adjusting diff after an idle/reconnect would keep server and miner in sync and avoid the temporary “high diff …/old_diff” burst.

[-ck]

Functionally, I agree it’s minor: the rejects are low-value shares and the window is short. I only want to flag it for ck because it spikes the reported reject metric when it happens on a high-vardiff miner, even though nothing is actually wrong.

If this is intended (new diff applies on next notify/job only) then all good; if not, perhaps forcing an immediate notify when adjusting diff after an idle/reconnect would keep server and miner in sync and avoid the temporary “high diff …/old_diff” burst.

Here's the protocol documentation linked that describes new diff, which is meant to apply to the next notify. Mining hardware and other software may have not implemented it this way, but ckpool has.
https://bitcointalk.org/index.php?topic=557866.msg6078264#msg6078264

[Nexus9090]

-snip-

Thanks for the suggestion. Just to clarify: I’m not manually setting vardiff. I let the pool handle difficulty based on share rate. What I’m seeing seems to come from the pool’s own adjustment logic around brief idle/reconnects, not from me forcing a diff.

Here’s a clean example that illustrates it:

[2025-10-31 09:19:25.156] Accepted client passthrough:1 subclient:16304 share diff 27153.7/21232/156T: 00000000000269da05f78f4166a9aa29c777b28793a371caf708ab784b97f6cc
[2025-10-31 09:19:25.156] Client passthrough:1 subclient:16304 biased dsps 60.27 dsps 60.27 drr 0.00 adjust diff from 21232 to: 201

Miner briefly disconnects/goes idle, dsps drops, and the pool decides to lower vardiff from 21232 to 201. After the miner comes back, it has adapted to diff 201, but the pool is still evaluating submitted shares against 21232 for a short window:

[2025-10-31 09:19:33.061] Rejected client passthrough:1 subclient:16304 high diff 491.8/21232/156T: 0000000000853ded4f5115985496eb55a91bcb49c372221dadd294d7e68512c7
[2025-10-31 09:19:33.066] Rejected client passthrough:1 subclient:16304 high diff 630.4/21232/156T: 000000000067f3cfce387abd9f6d9c6880a979d0a718607017cd684f8ef5d8c2
[2025-10-31 09:19:33.169] Rejected client passthrough:1 subclient:16304 high diff 725.5/21232/156T: 00000000005a53cd9334ff0718149e1d913df7f512b3a525b44fa72d0bb86dde

Functionally, I agree it’s minor: the rejects are low-value shares and the window is short. I only want to flag it for ck because it spikes the reported reject metric when it happens on a high-vardiff miner, even though nothing is actually wrong.

If this is intended (new diff applies on next notify/job only) then all good; if not, perhaps forcing an immediate notify when adjusting diff after an idle/reconnect would keep server and miner in sync and avoid the temporary “high diff …/old_diff” burst.

OK well, this issue must be something peculiar to your mining software and set-up.

With CGMiner, this error only occurs once at start-up when the requested diff is applied; after that mining carries on indefinitely with the requested diff no drops or idles. The same is true of ESP-Miner on the BitAxe devices. With CGMiner if you do not specify a diff then the pool assigned diff is applied and I have never seen a dropped share when that is the case again same is true on ESP-Miner.

So the only conclusion I can come to is, it must be a peculiarity of the mining software you're using.

Just out of interest, what system and SW are you using?

[novaqula]

Hello,

I would like to know if CKPool is running Bitcoin Core v30? If not, are you planning to do so? I'm asking, because version 30 contains harmful changes for Bitcoin network and there are plans for soft fork, which may cancel blockchain build on Core v30 software.

Many thanks in advance for your reply.

[NotFuzzyWarm]

...
I would like to know if CKPool is running Bitcoin Core v30? If not, are you planning to do so? I'm asking, because version 30 contains harmful changes for Bitcoin network and there are plans for soft fork, which may cancel blockchain build on Core v30 software. ...

Great, another noob Cult of Luke follower who drank his kool-aid...  
Safe bet that if he has not yet upgraded to it, -ck WILL be running core 30. Knots is the version that is screwing with BTC by enforcing censorship of tx's which goes against the whole point of Bitcoin.

[novaqula]

Great, another noob Cult of Luke follower who drank his kool-aid...  
Safe bet that if he has not yet upgraded to it, -ck WILL be running core 30. Knots is the version that is screwing with BTC by enforcing censorship of tx's which goes against the whole point of Bitcoin.

The very begining of your reply shows your arrogance and lack o mannes. That's just sad.

No, I do not care for Luke and I do not agree with a lot what he's saying, as he's an extemist for me. I do care however about the Bitcoin in which I've put my lifes savings. What core devs done with version 30 is simply dangerous for Bitcoin network in my opinion and I disagree with their decision. Bitcoin is a monetary network and I want it to stay as such. I am also solo mining with CK Pool and if CK is using Core v30 I would like to know, because if they do, I will cease mining with them. I dont want to support spam and dangerous arbitrary data on Bitcoin network. Thus, my original question.

[BlackHatCoiner]

I am also solo mining with CK Pool and if CK is using Core v30 I would like to know, because if they do, I will cease mining with them.

Maybe stop mining bitcoin altogether as bitcoin allows the inclusion of this arbitrary data in case you didn't know it? Core simply did not consider it standard all this time, but "spam" generally does get included in blocks since 2009.

[-ck]

I normally update the pool bitcoin nodes about 3 months after release, and will do so again with v30. This is not up for debate, any further posts about potential shitcoin forks will be deleted. Feel free to mine elsewhere.

[willi9974]

Short question @-ck
Segwit Addresses like this is fully supportet for solo mining?

37XwW2eTKWCvRYK3B7fiLid8Zdtt7p7pwg

Best regards,
Willi

[duckAxe]

Short question @-ck
Segwit Addresses like this is fully supportet for solo mining?

37XwW2eTKWCvRYK3B7fiLid8Zdtt7p7pwg

Yes, look @ https://bitcointalk.org/index.php?topic=5237323.msg54292870#msg54292870

[MrJaekin]

Can I mine directly to a Trezor?
bc1qqstjnxdgmd8p9ddt28npur0crt33lhgpevhn63 - Bech32 (P2WPKH)

[NotFuzzyWarm]

Yes. You are not mining to any given wallet or device. You mine to an address on the BTC network and as long as you control it you're good to go.

[willi9974]

We're starting again

let's go to the next group buy from Hashingpower.

As already requested by some forum users I put a new group buy for solo mining. Start at the earliest after the next diff reduction.

~10-20 users for each 0.005 BTC, 0.01 BTC or more BTC can participate. A higher number is not useful, otherwise a possible profit will be much too small.
If smaller amounts than the minimum amount are allowed in a single case, then the calculation of the rewards will be based on the amount of BTC deposited.
Hashingpower is rented on MiningRigRentals and shot on the solo pool.
The status of the group run can be observed during the runtime via the Live View link.
Here you can see what our hashingpower is and what our highest share / bestshare is.

If a block is found, the reward will be paid out to the participants.

In the past we had found 10 blocks --> 193 BTC!
Block list: 385022, 394940, 394946, 395087, 396941, 399709, 401934, 706369, 712217, 780525

Those who want to participate send their BTC to the following address bc1qay3yk0ew90rvx20mmj4s3ep8x8997kvlf8pexp and post their participation with the following template:

Please send your coins only if there is still a place available.


To make it a little easier in the new year, I've decided to do the reservations differently.
In the new year there are reservations possible for people who pay for 2, 5, 10, ... block party runs in front.
If the quota is exhausted, the place will be automatically free and someone else can use the place.

Specifically, we start with the Blockparty Run 2025-1 and if someone sends 20x 0.01 BTC at the first time, he is practically permanent until the Blockparty Run 20.
If someone joins the Blockparty Run 2025-7 and sends 10x 0.01 BTC, he will be a member until Blockparty Run 17.
This simplifies the organization and places are not permanently taken by the same people, unless someone sends 20x 0.01 BTC for the 20 planned Runs.

If we should not create at the end 2025 the Runs, for which someone already paid, the last Run in 2025 all payments are used around longer to run or we user the founds for next year.

As long as open slots are available the coins can be sent at any time without an OK from me

More details here

English topic: https://bitcointalk.org/index.php?topic=5564781.0
German / English mixed: https://bitcointalk.org/index.php?topic=5564593.0

Fingers crossed and join the party for cracking a block
Willi

[Nexus9090]

We're starting again

-snip-

Fingers crossed and join the party for cracking a block
Willi

Good luck Willi, hope your team wins a block.

[leandrovitorl]

Is the swimming pool working properly?