[∞ YH] solo.ckpool.org 2% fee solo mining USA/DE 255 blocks solved!

[Gws24]

Ofcourse I can't say for sure if there are or aren't miners withholding blocks on nicehash but I've found multiple blocks using Nicehash on this pool so from my standpoint so far it's not a big problem (or I've been incredibly lucky). I do however think that Nicehash should be monitoring it as -ck says.

[thedreamer]

So how do miners then do block withholding?

That's something I'd rather not educate people on how to do.

I wasn't asking on instructions how to do it, but then how do we tell if a rental or anyone is doing it as I have read you write they are?

I mean , logically, if we don't know, how do we know it REALLY exists. It's the falling tree in the forest dilemma.

[-ck]

So how do miners then do block withholding?

That's something I'd rather not educate people on how to do.

I wasn't asking on instructions how to do it, but then how do we tell if a rental or anyone is doing it as I have read you write they are?

I mean , logically, if we don't know, how do we know it REALLY exists. It's the falling tree in the forest dilemma.

If by "exists" you're asking whether someone out there is intentionally or unwittingly block withholding, I cannot answer the question though there have been pools that have inexplicably bad luck from entities in the past that they then blacklisted which turned out to be faulty miner hardware/software designs allegedly rather than malice (as if they'd admit to that anyway).

As for a mechanism to do it intentionally, yes it "exists".

[thedreamer]

Ohh.. So it was not been proven yet that it actually can be done maliciously then??

KANO has numerously referred to it from rentals like nicehash and westhash and is actively blocking them 'due to that reason'.
So there is really no merrit to that then?

Sorry for all the questions, but I just want to get educated on this issue as I do rent hashrate to pools every now and then and
nicehash is the easiest way to rent large PH++ .

I did notice that when a large rental form NH/WH is active to this pool, the share-rate barely increases vs a bunch of small single miner
rentals. the other week I hammered solo pool with 10ph for a while and it made little difference.
(Albeit it was rentals from MRR where a rig owner was just re-renting NH hashrate turns out).

[-ck]

Ohh.. So it was not been proven yet that it actually can be done maliciously then??

Do you want me to prove it? Unfortunately I don't have hundreds of PH at my disposal to convince you but if you set up a low diff testnet pool I can mine at it for days without finding a block for you.

[Gws24]

-ck, since 'the other guy' is blocking NH from his pool I assume that NH uses specific ip-addresses or something that identifies a NH rental? If so, could you then not also do an analysis of these rentals on the solo pool? I'm not saying that you should because the burden is with NH itself but I'm just wondering if it could it be done? (if you had the time and inclination to do so which I'm guessing you don't  )

[-ck]

-ck, since 'the other guy' is blocking NH from his pool I assume that NH uses specific ip-addresses or something that identifies a NH rental? If so, could you then not also do an analysis of these rentals on the solo pool? I'm not saying that you should because the burden is with NH itself but I'm just wondering if it could it be done? (if you had the time and inclination to do so which I'm guessing you don't  )

To do a meaningful statistical analysis I'd need to get 10 x diff shares from NH. At this pool's hashrate that would take about 3 years, assuming all the hashrate came from NH, which it is not. Meaning even if I wanted to do such an analysis, I can't. Proving block withholding is actually very difficult and always has been.

[ComputerGenie]

And every bit of that data would have to be specific to this pool (as any shitcoin rental would skew the data set).

[thedreamer]

Interesting test I did today. I was bored. LOL

With 3.4-3.6PH the pool averaged 204-205 SPS.

I added a 3PH rental from nicehash and westhash to the pool for a while and the share rate only increased to 208SPS average.
Shouldn't it have gone up quite a bit more than that?

[-ck]

Interesting test I did today. I was bored. LOL

With 3.4-3.6PH the pool averaged 204-205 SPS.

I added a 3PH rental from nicehash and westhash to the pool for a while and the share rate only increased to 208SPS average.
Shouldn't it have gone up quite a bit more than that?

They use proxies which combine the shares from multiple machines into much less connections.

[thedreamer]

Interesting test I did today. I was bored. LOL

With 3.4-3.6PH the pool averaged 204-205 SPS.

I added a 3PH rental from nicehash and westhash to the pool for a while and the share rate only increased to 208SPS average.
Shouldn't it have gone up quite a bit more than that?

They use proxies which combine the shares from multiple machines into much less connections.

Does that mena less shares are actually transferred to the pool then? Just a fictitious hash rate increase, but no real increase in shares?

[-ck]

Interesting test I did today. I was bored. LOL

With 3.4-3.6PH the pool averaged 204-205 SPS.

I added a 3PH rental from nicehash and westhash to the pool for a while and the share rate only increased to 208SPS average.
Shouldn't it have gone up quite a bit more than that?

They use proxies which combine the shares from multiple machines into much less connections.

Does that mena less shares are actually transferred to the pool then? Just a fictitious hash rate increase, but no real increase in shares?

Diff

[thedreamer]

Interesting test I did today. I was bored. LOL

With 3.4-3.6PH the pool averaged 204-205 SPS.

I added a 3PH rental from nicehash and westhash to the pool for a while and the share rate only increased to 208SPS average.
Shouldn't it have gone up quite a bit more than that?

They use proxies which combine the shares from multiple machines into much less connections.

Does that mena less shares are actually transferred to the pool then? Just a fictitious hash rate increase, but no real increase in shares?

Diff

Huh?

[-ck]

Huh?

The bigger the hashrate the higher the diff, the shares per second are constant depending on number of connections.

[thedreamer]

Huh?

The bigger the hashrate the higher the diff, the shares per second are constant depending on number of connections.

So with a higher hash rate, and thus a higher diff, does the chance of solving a block go down or remain the same?
Sorry, I'm not following how all this works. 

[ComputerGenie]

Huh?

The bigger the hashrate the higher the diff, the shares per second are constant depending on number of connections.

So with a higher hash rate, and thus a higher diff, does the chance of solving a block go down or remain the same?
Sorry, I'm not following how all this works.  

Share diff is the equivalent of the server saying "Don't send me any shares that are less than a difficulty of x". For a given hashrate, if x were 100 (for example of small easy to talk about numbers) then the amount of times that amount of has "should" return shares would be 10 times per second (for example of small easy to talk about numbers). If you doubled that amount of hash, and kept x at 100, then you'd return 20 shares per second.
The value of x fluctuates with hash in order to have a specific number of shares returned per second/minute, otherwise an huge hash increase would dump 300 gajillion shares and pointlessly flood the server.

All shares that are returned for any difficulty lower than an actual block solve are solely for the purpose of the pool giving the users credit for their work (albeit that has no real meaning in a solo pool). To that end, there's no difference between 1 share at 100 or 10 shares at 10, other than the load on the server; so, the per user/hashrate diff is adjusted for that given hashrate and all users return roughly the same number of shares per second/minute.

[thedreamer]

Huh?

The bigger the hashrate the higher the diff, the shares per second are constant depending on number of connections.

So with a higher hash rate, and thus a higher diff, does the chance of solving a block go down or remain the same?
Sorry, I'm not following how all this works.  

Share diff is the equivalent of the server saying "Don't send me any shares that are less than a difficulty of x". For a given hashrate, if x were 100 (for example of small easy to talk about numbers) then the amount of times that amount of has "should" return shares would be 10 times per second (for example of small easy to talk about numbers). If you doubled that amount of hash, and kept x at 100, then you'd return 20 shares per second.
The value of x fluctuates with hash in order to have a specific number of shares returned per second/minute, otherwise an huge hash increase would dump 300 gajillion shares and pointlessly flood the server.

All shares that are returned for any difficulty lower than an actual block solve are solely for the purpose of the pool giving the users credit for their work (albeit that has no real meaning in a solo pool). To that end, there's no difference between 1 share at 100 or 10 shares at 10, other than the load on the server; so, the per user/hashrate diff is adjusted for that given hashrate and all users return roughly the same number of shares per second/minute.

Ahh. Got it. Thank you! 

So basically a large rental will stay 'about' the same SPS rate but will be transferring a much larger data packet/share with more difficult numbers (possible solves) in it.

[wavelengthsf]

Ahh. Got it. Thank you! 

So basically a large rental will stay 'about' the same SPS rate but will be transferring a much larger data packet/share with more difficult numbers (possible solves) in it.

Yes -  ckpool's share diff adjusts to support a standard rate of accepted shares. The minimum it'll allow is 1 million using the rental port, but it can of course go higher. (If a share diff is above the network difficulty, you get a block.)

[tommycrypto]

Hey guys!

I'm a newbie here.  

Can you please tell me how to check that I pointed my S9 to solo.ckpool in correct way?

{
 "hashrate1m": "8.07T",
 "hashrate5m": "13.5T",
 "hashrate1hr": "17.9T",
 "hashrate1d": "1.84T",
 "hashrate7d": "275G",
 "lastshare": 1524772684,
 "workers": 2,
 "shares": 40000000,
 "bestshare": 36400871.73692238,
 "bestever": 36400871,
 "worker": [
  {
   "workername": "16U5HDYhpW5ZxEX6MLofPCSh2tAumM932r",
   "hashrate1m": "8.07T",
   "hashrate5m": "13.5T",
   "hashrate1hr": "17.9T",
   "hashrate1d": "1.84T",
   "hashrate7d": "275G",
   "lastshare": 1524772684,
   "shares": 40000000,
   "bestshare": 36400871.73692238,
   "bestever": 36400871
  }
 ]
}

And the main question: How can I "examine the coinbase and template sent to you over stratum" to confirm that I'm mining to my own address? Is there any simple way?

Sorry for noob  questions  

Thanx beforehand!

[ComputerGenie]

...to confirm that I'm mining to my own address?...

The fact that you get your info back from inputting your address means that you did that already. Don't over-think it and confuse yourself.