It seems people on that other pool have been too used to ck posting incorrect information ...
So I'll add a simple explanation of 2 numbers:

The total solo work since solo started is 146.95%

The 3708.2% is how good the share was - i.e. WAY higher than needed to find a block
and our new record high share - 3.267P - well above the required 88.1T

heh - actually while I'm not in any way contradicting your explanation,
since it is correct, however one minor correction, is that the block number is in the block's coinbase transaction.

The first bytes of the coinbase sig must contain the block number.
Thus the block's merkleroot effectively contains the block number.

The reason this was added later, but not there originally, was due to the risk of duplicate coinbase transaction numbers.
I'm pretty sure there was once a case of a duplicate transaction number, and this was the fix to ensure it didn't happen again.
The coinbase transactions originally didn't actually know the block they were in,
so a pool could generate 2 coinbase transactions, at different times, for different blocks, with the same transaction hash.
Adding the block height to the coinbase transaction sig, meant that the coinbase transaction contents couldn't be the same.

--

Anyway, it's not a 'success rate', it's simply an 'expected' number of blocks for a given amount of work.

While all the other small pools get this calculation wrong (and falsely show better luck numbers than they are getting)
the 'expected' number of blocks is simply 1 per 100% of work done.
The 100% number is calculated as the sum of all (work/netdiff) per every 2016 blocks

The catch there being that you can't divide your total final work by the current network difficulty, since that's faking better results for small pools.
An example would be, if you have done 50% work in the previous 2016 blocks, that 50% says fixed, and you add on top of that the amount of work you have done in the current 2016 blocks ... and so on over time until you find your next block.
On all the (other) small pools, that 50% suddenly drops after a diff increase, since they are not storing that 50%, but recalculating it incorrectly at the new network difficulty at the time the block is found.

I posted this simpler explanation in ckpool solo, but he didn't want his miners to know and deleted it:

The terms: pplns mining, solo mining and PPS(xyz) mining, refer to how the rewards are distributed.

It should not matter who generates the template, if they are using the basic bitcoin getblocktemplace command, and not fucking with the transactions selected i.e. not being stupid and using stratumv2 or modifying the transaction list returned by get getblocktemplate, before distributing the merkle slice to the miners.

In the case of my pool, it is indeed free of such transaction bias.

The point of using my resources for mining, PPLNS or SOLO, is to have one of the best, worldwide, block distribution networks around, to minimse the chance of losing your block due to being orphaned.

Finally got our first solo block on the pool - well done to the winner of the block.
I'll leave it up to him to say he got it

No you wont.

Mining is simply: generate a header, then run the nonce from 0 to 2^32-1
Changing that nonce order will have no effect at all on luck - zero - none - absolutely no reason to do it.
You also cannot selectively choose nonces that will give better results - since you have to hash the nonce to find out - which is what a miner does.

Well you can only buy hashpower to run solo of course.

I'd highly suggest you stay right away from MRR - had a few complaints to me about sending hash rate from MRR.
Alas in all cases it's either been a problem at their end, or miners connecting directly to the pool with banned firmware.
The complaints flared up when MRR wouldn't reimburse them for hashes not sent to the pool,
which, to be blunt, is a scam.
Cost for hash rate there was ridiculously high,
and since the number of hashes you get determines the chances of you getting a block,
overpaying for hash rate is simply reducing your chances of getting a block.

The issues with FuckHash are a long history of scamming and lying about the rewards for miners.
While I certainly don't like them, and certainly would not trust them for spending a lot on a large amount of hash rate,
alas they are the most reliable for buying hash rate at the moment.

From your info, the pool will report correctly what the real hash rate is.
If the miner is constantly reporting higher, then there's something wrong with it's reporting.

Only other thing I can think of is it's sending hashes somewhere else that makes up the difference.

Well most miners take an hour to actually get an average close to what they are really doing.
If you are running any 3rd party firmware, and the pool isn't blocking it, they are also taking a % of your hash rate.
The workers page on the pool gives lots of details about each miner and the invalids,
and Help->Stats explains a lot of that page if you are logged in.

A few simple points:

1) Even if it does happen, it wont be Bitcoin, so it wont matter.
A fork of Bitcoin is not Bitcoin.
Bitcoin works no matter what the price, and even a large drop in hash rate has no real effect on that - as expected, and as we saw, when china shutdown mining.

2) The magic 51% number rears it's head yet again
Pools mining against lower points in the active chain will be obvious.
So it would become immediately clear what pools not to mine on.
Excluding higher paying transactions means less mining reward in your block.
Excluding the lowest paying transactions, when block space is at a premium, is how Bitcoin works.
Messing with that means less bitcoin reward for mining.
(Which is what StratumV2 is trying to make happen - stay away from V2 - they're probably backed by the gov't since they are helping to do this)

3) It's the current us gov't that's trying to damage Bitcoin, not sure why anyone in Bitcoin would want to keep them in power lol

No pool does what is described above.

Since it is 'prediction' that means there is the chance of it being wrong.
Thus the pool would be mining an invalid block, until they corrected the mistake.
My bitcoin logs would show these invalid blocks coming from these large pools also.
Building a block beforehand doesn't save anything worth doing ...

The time to fully process a block on my pool is less than 100ms.

Thus any pool that can do a block change in 0ms (which isn't possible), will only gain one extra block, every 6000 blocks they find, vs my pool.
i.e. a 0.0167% gain. Though it will be lower again coz nothing takes zero time to do.

Orphans are not common any more, so discussions about large pools winning against small pools is pretty much pointless and irrelevant.

People keep quoting ridiculously large times to do block changes like 5-10 seconds.
The average time to do block changes will determine how often orphan races occur.
If it was 10s then there would be 10/600 % of blocks being orphan races i.e. 1.7% i.e. about 2.4 orphan races EVERY SINGLE DAY.
Clearly that is not the case. Yes some pools will do slow changes - a minority - crappy pools with badly written code and poor network connections.

Even if it was 3 seconds, the expected number of orphan races would be about 1 every 1.4 days - which is not the case either.

Clearly wrong since most large pools have mined empty blocks for a long time.

The work diff has no effect on your chance of finding a solo block.

When solo mining, the pool's work diff ensures it provides regular feedback, so that the hash rate the pool shows has low variance.
If you set it too high, the hash rate on the pool will jump all over the place and effectively be meaningless.

The option to set it high on a solo account, is in case you do a rental that requires a high diff before it will work.
The only other use for setting the diff on solo (or pplns) is to set a higher starting diff than the pool default of 8190,
if your miners normally run much higher i.e. so they don't send a bunch of 'hi' ignored shares when they connect.

In all cases, once the pool corrects the diff after you connect, the pool's diff is the best diff to use.

No comment

Except that tiny hash rate miners are a complete waste of time and an excessive waste of power.
CPU and GPU mining are very good examples of this excessive waste.

With GPUs, to do 130TH/s like a single one of my ASIC miners, that uses about 3.5kW,
you would need 65000 GPUs doing 2GH/s - now if they are crappy GPUs that only use 100W (though they can't do 2GH/s)
that would be 6.5MW of power to do 130TH/s vs 3.5kW ASIC
Yes that 6.5MW would be a ridiculous waste of power.

Meanwhile, 130TH/s only has a 1 in 28871 chance of finding a block in a day.

With CPU mining it's WAY worse.

Mobile phone mining is usually a virus - stay well away from destroying your phone and your battery with mobile phone mining.

... and to top it off, no single CPU or GPU or Mobile mining will earn you any BTC.

My miners use the original firmware

No idea if it can find a block, but proof it can hash >32bit shares - which is one well known historical example of losing blocks ... that happened on slush

Vnish is a full on lying bunch of scumbags who also violate my cgminer license.

Mine here solo for the ridiculous low 0.5% fee

If you want to do it yourself, then be prepared to spend $15k a year on fast bitcoin nodes to distribute you blocks around the world.
Of course it will still be slower than here.

Yes - as NotFuzzyWarm stated it is now allowed for that exact reason.

The main issue with most if not all miner developers, is they are hackers without any tertiary computer education, and haven't worked in the computing field doing any sort of critical software development.

They wont test their software properly and expect problems to be the problem of those paying exorbitant fees for the software.

So here, with hack firmware like the apollo and braiins, I required them to find a >32 bit share before risking them running on pplns - since mining on pplns is forcing sharing that risk with everyone else on pplns.

Also, for the same reason, since I'm the largest miner on the pool, I don't want to be sharing my rewards with people running untested software that might throw away blocks.

Bitcoin mining is abound with known license violations and hack software.
To be blunt, I don't know of anyone who doesn't fall in that category (except me)

Indeed the faster your share gets to the pool and it verifies it then sends out the block to the network,
the less likely it will be stale and/or orphaned.

That's why we have 9 nodes around the world for both receiving your shares faster
and also distributing blocks around the world as fast as possible
- most likely faster than any other pool since we don't even send the blocks,
we only send a single tiny share to all the nodes so they can send the blocks out to everything in their area as fast as possible.

Well my only guess would be check the username, since it's case sensitive.
I have it on an iPad and it's working at the moment.

As it says, read the README file.
You prolly didn't setup the USB miner as explained in the README file.

Are there PPS pools that don't show a reward for all shares?

Do you mean you've been holding back rewards before now, and finally are rewarding people for mining when they do it?