Alas, as I keep reminding you, that calculation is actually wrong.

So while you are saying 1.7% is good, and higher is better, it is actually quite a bit higher than that.

ckpool software does not store or display the information required to calculate that correctly, so his reported blocks usually claim much better luck than it is.
(not sure why anyone would be happy about that ... but anyway)

As I've explained a number of times, the problem is that shares/diff must be added up per difficulty change,
b ut using a total shares / current diff is far from correct.

To make it clear in a valid example, if you did 1% diff for 2 weeks and difficulty was 100T,
but later include that in a 110T, suddenly that 1% diff has dropped to 100/110 = 0.91% diff
The % amount of work done hasn't changed, but the calculation has ignored that.

To give an example that may explain it better, but not very realistic,
Image diff is 100T and you do 50T work during that 2 weeks, you have now done 50% of a block work.
Then say next diff, it jumps up to 125T, so at the start of that 125T diff, suddenly the amount of work you have done drops,
if you calculate it incorrectly using 50/125 = 40% work
But you haven't done any less work %, just the calculation is wrong.
The work % value of a share, is based on the difficulty when the share was submitted, not much later when difficulty has changed.

When finding a block lasts for a few weeks or months, that % difference, when calculated incorrectly, becomes very noticeable and makes the pool look like it is luckier than it is.

It is VERY easy to calculate your expected reward on any PPS/FPPS pool if you simply look at your accepted shares on your miner.
I very much doubt any of the big pools would get away with claiming PPS or FPPS and not paying it, since it is so damn simple to check.

Running a rental from fuckhash is probably the worst way to test a pool, since you have no access to the miners at all, and no access to statistics, just a randomly allocated hash rate that may well be nothing like they say it is and nothing like you paid for.
We run a 'solo' fun run in my pool using fuckhash, and looking at the expected result vs the actual result, it's quite obvious they like rounding things down.

ALL pools work off share difficulty - hash rate is simply a calculation from that.
Alas when fuckhash only show you hash rate, it's really hard to tell what's actually going on and how much you lost vs what you should have got.

I do hope your pool also supplies valid statistics and isn't hiding behind unreliable calculations.

Aside: miners also do the same thing to show hash rate, it's also a calculations based on nonce difficulty found by the chips over time. (and it's also not a count of hashes)

Heh - unless you blew all that 20-30k BTC you had, clearly having $1bil hasn't changed you for the better

Simple fact, there's not 10-15% more BTC per block, than most pools pay.
So unless someone mining on your pool is giving away a very large amount of BTC constantly, to everyone else mining, it's not possible to pay 10-15% more than other pools.
Simple math and logic, alas I know such concepts usually elude you

They were shelved - lol
... and wiz took a nice large txn to himself when everything closed down.
Will be fun to see this happen on ocean as well

I noticed what may have been you attempting to login.
The failed login accounts both have some sats in them, but alas less than $1 in BTC - less than 1000 sats - so well under the dust limit.

lol - did someone hack your account?

That statement is clearly false.

If you saved the '2FA Secret Key' when you setup 2FA (as it tells you to do) then you can manually use that to setup 2FA on a device.
If you supplied a '2FA recovery phrase' when you setup 2FA, then the password reset will allow you to use that phrase to remove 2FA.
If not, then no, there's no other way to access a 2HA account without 2FA.
Yes it is secure, no it will not allow someone else to access you account without one of the above.

It was permanently blocked a few months back for accessing the API with many random garbage usernames,
and usernames with hex codes in them.

The two usernames that were valid before the flurry of invalid usernames,
were accessing the API way more often than the limit and way more often than what you said in PM,
so I take it you have no control over that access rate so you should set it like other apps:
access the pool from the app, not pass their information to your servers,
that way when the user exceeds the rate, only that user is blocked.

I must be a Solo account

Account->Solo has the option to allow you to set it higher.

Test setup the pool in Fuckhash,

This will create the worker

Under Worker->Management set the worker with high diff

Then it will work

Only what bitcoin core accepts.

Sigh ...

lol - even the people who designed and made the ESP32 disagree with you

2 things:
1) Yes you can calculate luck correctly. I do on my pool. Just you can't on ckpool because he doesn't store the necessary information to do it.
2) Luck is ONLY a measurement of historical values, you cannot predict it.

Lulz - yeah I've literally never sent spam to anyone - ever.
The outgoing server is my own AWS that I've had for a very long time also, so yeah sounds like a bunch of retarded RBL managers.
One big problem with the RBLs is that random people can push you onto them.
Last time I checked, most of the (few) I was on were in russia and were false listings - and you have no chance getting off them.

Interesting you say I'm now on a lot of them, it was only 4-6 last time I bothered to look last year.

They all suck up hard to microshaft and other large email providers so that they don't block most email,
but like to cause problems for small email servers.
Thus when anything shows up, I remove it.

Well since you know what an RBL is, you'd have to check the relevant ones to determine if it is still in the list or not.
I don't keep track of them once I fail to be removed, so it would depend on the domain.

There are also a lesser few that I block for other reasons, but it would of course depend on the actual domain.

So many times ... I've been running email servers for over 25 years.

Some of them also have no way to be retracted.

Some email addresses can't be used coz they falsely decided my mailserver is a spam source.
Considering how few email messages are sent out, and they are only sent to people for account notifications, it's really just a royal PITA.
So if the web page says you can't use an email address, it will be because the mailserver you want says I'm a spam source.

Other than accepting txns that standard core might not, for any other reason it, to be blunt, seems an odd thing to do.

I guess one use would be, to hide that you've succeeded in stealing someone's BTC, and then there's no chance they could RBF it.

Another point would be that it would delay the transaction.

Since the transaction is going to go public as soon as it ends in a block, I'm wondering what's gained by not distributing your transaction to the network before that happens.

Well next change I do, you'll need to have your account verified and a payout address on both
types.

Verified is obvious - if you don't verify your email you could have one that doesn't work or you
mistyped it (which happens on occasion) so if someone else logs into your account,
coz they got your password from various mistakes people make,
and changes the payout address, you wouldn't get the notification
- and you'd not get any other account change notifications

A payout address is obvious, especially on solo where it's a lot of BTC for anyone who finds a block.
I'm not a bank, I don't want your BTC, so if you get a block on solo, I send it to the payout address,
and thus I don't need to find someone and get their info
e.g. block 847367 I have no idea who they are, never chatted with them, and no info about them except
their email and payout address, so I didn't need to go find them and harass them for a payout address,
they already had one (as per required)

The no-mining is simple, it completely avoids the problem of me having to deal with someone
changing their account after mining a pplns block and expecting me to pay the whole block to them.
Your account type is obvious - bold red, top left when you login.

The current 'switch' was to make it easy to add the option at the time I implemented it.
Next changes, you'll select the account type when you create the account and can never change it.
It will have the restriction that you have to verify your account and set a payout address before mining works,
so effectively the same in that regard.