...
Are you lifting the firmware restrictions to solo miners?
Well, if you mean illegal firmware violating the cgminer license, put out by hackers on this forum who charge ridiculous fees ...
why would I be happy about supporting people using that?
Of course not.
As for rentals, or that 'other' legal firmware,
that's part of the reason why it's not ready yet ... though that part is complete, but requires the rest of the solo code to be complete of course.
The new system completely automatically disconnects and bans miners when they connect, and can also ban their IP permanently.
Some of the banning in the past was automatic and some required me to trigger it manually when I checked things.
The new one is fully automatic, but it doesn't replace the old one, just adds another method to do it.
It also has an option in those rules to allow solo users for some of the rules.
If you want to risk using some rental source, it will allow you to do that for some rental sources on solo.
It also means I am able to more easily detect issues related to where different types of mining are coming from and what they are using.
i.e. KDB now includes reports of it immediately upon request.
CPU/GPU will always be banned since they are a waste of any pool's resources, and you'd require millions of them to match a single miner ...
Edit: even a tiny NewPac USB miner is over 1000 times faster than a CPU and over 100 times faster than a GPU
Edit2: the next update also includes the correction of the pool block difficulties, since the pool has now got so small.
Using the TotalDiff/NetworkDiff is incorrect.
While in the past, we were a much larger pool, and this made negligible difference and on only a very few blocks that crossed difficulty boundaries, over the past year this has been clearly incorrect and noticeable (like all the other small pools has for years ...)
With the update, blocks in the last year will be updated also, and the new code (in testing) already handles this correctly.
It is actually a major issue in calculating the value correctly also even using the largest language double value available in C, due to lack of precision.
Using a running total also gives rise to incorrect values, however, as has always been the case here, KDB shows an estimate first when the block is found, but re-calculates it with an update. The new estimate is calculated correctly but contains the small running precision issue, that gets larger as the number of shares increases, however the re-calculation resolves that by grouping results within shifts, within difficulty ranges, before doing the calculation.