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, 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  )

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

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

Diff

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

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.

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

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.

And, strictly speaking, I believe a higher hash rate has the same chance to find a block as a lower hash, but it should find one more frequently.  But maybe that's the same thing as a better chance...