WADR, I'm not looking for a workaround. I reported a design issue in the implementation of the feature
and its effect on usability. I also suggested a way to solve it. It's a matter of UI consistency.

Thanks, but if I do that I can't switch to bump score. With the current implementation the only way
to have bump score sorting is by default. If you switch to somthing else you can't switch back.

It's contradictory that bump score sorting is forcedencouraged by being the default but
it can't be selected manuallly.

I have a concern about the implementation.

It introduces a new sorting scheme while bypassing the existing sorting controls. It is possible to select
sorting by last post, or any other column, but no way to return to bump score sorting without jumping through
hoops (I don't like jumping through hoops).

IMO the way to have implemented this would have been to create a new bump score column which can be
used as a sort key like any other column.

An added bonus would be to have a user defined default so people who prefer last post sorting, like me,
don't have to constantly set it manually (more jumping through hoops).

By using PTX you're esentially using a proprietary language to prevent anything but a Nvidia product
or a Nvidia licensed product from mining your algo. That's one way to make an algo ASIC/FPGA resistant.

I wouldn't do that if I were you. There's a problem with the BorisJohnson blockchain,
it keeps forking, is full of orphaned blocks, and can't confirm any transactions.

The problem is x16rv2 isn't any more ASIC resistant than v1. All it really needs is development
of a Tiger kernel which shouldn't be too difficult. The only thing that would prevent it is lack
of market demand. Lyra2v3 has a similar problem.

It's not easy to make an algo GPU friendly and ASIC resistant. It would have to target a resource
that GPUs have in abundance that would be too expensive to implement on an ASIC. I'm not aware of any.

Permuted instructions can be worked around with a RAM code segment so it just increases RAM requirements.
A bigger dataset has the same effect. Ironically Lyra2REv2 used a smaller dataset than Lyra2RE to give GPUs
an advantage over CPUs. Lyra2REv3 did not change the size of the dataset.

In the end coins that fork to new algos periodically as an anti-ASIC strategy do little more than create
a planned obsolenscence environment driving demand for new ASICs.

So let me summarize:

A supposed c++ developper installs pool software for a feature without verifying the feature is present, configured,
or knowing how to use it, asks for help to use the feature, completely misunderstands the instructions,
blames the responder, challenges his competence, then whines about being insulted.

It's your competence that's in question.

There's a lot he doesn't know, like how to accept help when he asks for it.

It seems to be a common theme. The person trying to help ends up being
blamed and flamed.

It's pretty childish but it's fun to see if they ever figure out their own stupidity
or have to be spoon fed like a baby. We have the answer in this instance.

Any chance he'll come back and say I was right all along? Not likely.

It's your own fault you're confused, your second post made no sense. In your first post
you said you're using c=. Don't. Use mc= instead. How difficult is that?

A closed mind can't be helped.

c= is the payout coin, you want mc=

Maybe a little too subtle.

My response is if you have 20 computers try it and find out, if you don't try one computer and
multiply by 20.

As far as abusing company/school resources, go for it. The response from IT should be interesting.
Be sure to tell us all about it.

I did some more testing and it seems I'm receiving stale data from the pool. I'm getting data
regularly but sometimes it has an old job id.

There are no errors reported, I copy the data from the socket and it has the same job id

In the following you can see the sequence with a couple of debug printfs and annotations.


I hope this provides a clue of what's going on so it can be solved.

[sarcastic]

Don't be so pig headed, it's not that complicated. The profit of the parasites is near zero anyway.
Just mine LTC for a few minutes and see what other coins pop up in your pending list.

Whining about the design of the pool software is unproductive. Make a feature request to the devs
if it's that important to you.

[/sarcastic]

Mining is still depressed from the bubble bursting. The bubble caused an explosion in mining
but when the bubble burst all that mining didn't burst with it. All those ASIC miners and GPUs
don't just disappear. At the same time more efficient miners continue to enter the market
adding more to the mining glut.

I only mine part time now when electricity is cheap.

Precisely why tagging the scam posts important and why I started this thread, security in depth, as they say.

Keeping this thread (or any similar warning) on the front page will help discourage the scammers.

Yes tagging them is important so unsuspecting users are warned, but it's a game of wack-a-mole.
Poop has been tagging also.

Thank you for your good work.

My take on RandomX, cryptonight, Monero, etc.

As previously reported I have stopped trying to support the high level of algo development
by Monero and the variants of cryptonight. There exist excellent open source miners already
for this family of algos that are being actively developped. They are very well written with
little to no potential for further optimization.

In other words I have nothing to contribute. Trying to keep up would be a lot of work for no
benefit beyond the convenience of the additional algos in a single miner. Many Monero
miners are dedicated and don't usually mine other algos so the extra 100 algos would be just
bloat to them.

When and if development stabilizes and the dust settles I may consider re-importing
Cryptonight and RandomX and resume support.

I make no promises and there is no timeline.

TLDR: sharediff error was a bust, back to square 1.

I analyzed the code and did some testing to verify sharediff and the variables
used to calculate it.

The 256 bit arithmetic is done by converting the hash and target to double
using a simple polynomial:

This will introduce some loss of precision but not a 4x error. The resulting precision
matches the precision of the networkstratum diff which is also double.

NetworkStratum diff is obtained from the pool and matches, therefore correct.

Hash is as accepted by the pool, therefore correct.

Target is calculated from the networkstratum diff. If the target was too low if would produce
occasional low diff rejected shares, which isn't happening.

If the target was too high there would be no errors but the miner would neglect to
submit shares that would be accepted, resulting in a lower hashrate at the pool.
That was not observed.

In addition, I did some testing by raising the difficulty by 4x and low difficulty shares
were produced. 2x higher also produced low diff shares proving the original target
was neither too low nor too high.

The formula used:

sharediff = networkstratumdiff * target / hash

I can find nothing wrong with the sharediff calculation. It points back to the constant divisor
in the wiki arcticle being in error.

I'm willing ro accept it's simply a documentation error. My confidence in my code has increased
by doing a detailed analysis, however, it's still a hack without a proper explanation.

Edit: corrected references to stratum diff instead of network diff

There have been a large number of scam miner programs being posted here recently.

They are always closed source and only avaiable as binary files for Windows.
Crypto miners are the vehicle for the malware because they are known to generate
false positives by AV scanners and inexperienced users ignore the alert thinking
it's just another false positive.

Their ANN post tries to look legitimate, often copying text word for word from other miners ANNs.
They may post change logs to make it look like they have a history.
They may create github repositories with no source code, sometimes even claiming to be open source
with fake links that Windows users would never test.

They often target other newbies with claims of being easier to use.

There are a few clues to detect them:

Always posted by a newbie user.

Always closed source with only Windows binaries avaiable to download.

Slick ANN post with sprinklings of technical info often copied from others.

Real devs have credentials that can be verified: posting history, other work, testimonials from
trusted users, etc.

There have been several of these malware posts in the last week.

Any offer from a newbie user, especially closed source, should be taken with a healthy dose of
skepticism.

Stay alert and stay safe.