Topic: Change pushpool difficulty - [BOUNTY] (Read 5719 times)

Thanks for catching that. It should be hash32[6] actually because we should be checking the second to last 32 bit part, and the last is 7 because we start counting at zero. I'll edit my post.

Should this be hash32[7] rather than hash32[1]   (because of the little endian reversal)?
 

Oops, i meant the *miner_thread which is for CPU mining. And more specifically, the 4way algorithm. This is, of course, if you enable the fulltest function in util.c to return "rc".

No, cpuminer does not check for hash < target.

Ok, if not break, then it will have a tad bit more rejects, cause it will submit every H==0 because it does not check for hash < target. Only the cpuminer does.

You claimed that cgminer would break with a different difficulty.

cgminer and its ancestor, cpuminer, will push all H==0 solutions.  This is not the same thing.

Your income remains the same, either way.

Orly? How about checking the code in the gpuminer_thread or findnonce.c and tell me where you see a check for hash < target or even where the target is derived from?

No, that will not break cgminer.  All miners are built to handle any difficulty.

You're just confused.

Well no, cause then cgminer will be broken perhaps.

I've been looking at scalability of pools and completely agree that being able to change pushpool's difficulty is becoming an essential requirement, and will be even more necessary as hashing capabilities of improved hardware/technology increases, and as more people join pools as as difficulty of generating blocks increases.  

If we do make pushpool's difficulty changeable, how does this affect what antares mentioned though?  Will miner clients report lots of "rejected" shares, thus putting off people who are mining at a particular pool?  

If you don't change the hash checking code, miners could potentially submit targets that only meet the target:
00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
and not whatever you changed the target to, and still have those hashes be valid.

In other words, if I knew that you were feeding me the target 0000000019998000000000000000000000000000000000000000000000000000, but still had the checking code hard coded for 00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff, I could modify my miner with the target set at 00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff, and gain an unfair advantage by submitting hashes that don't meet the target 0000000019998000000000000000000000000000000000000000000000000000, but are still marked valid by the server.

What does rechecking that hash do?
I've found 2 blocks so far on the MiningFarm.com/stats.php on this difficulty change. With 10+ confirms for both.

Correct.  In addition to changing EASY_TARGET, you must update check_hash.

IMHO the bounty should go to the person submitting a patch that makes difficulty variable, without recompiling the source code!

First of all, for the config.c part, I forgot that the target should be specified in LSB byte order (the order of each group of 2 hex digits needs to be reversed)
For example, for the target:
0000000019998000000000000000000000000000000000000000000000000000
You would specify this in config.c as:
0000000000000000000000000000000000000000000000000080991900000000

The target:
00000000051EB333000000000000000000000000000000000000000000000000
Goes to:
00000000000000000000000000000000000000000000000033B31E0500000000

This:
00000000028F6000000000000000000000000000000000000000000000000000
Would be written as:
000000000000000000000000000000000000000000000000000F628000000000


Ah, I missed that initially.

So, for difficulty 10, we'd have the target:
0000000019998000000000000000000000000000000000000000000000000000

We can take the target and split it up into 32 bit sections:
00000000
19998000
00000000
00000000
00000000
00000000
00000000
00000000

The hash has to be less that the target, and the target is using Little endian (LSB first) byte ordering. So, in order for the hash to be less than the target, the first (last because of LSB) 32 bit integer must be zero, and the second integer (2nd to last because of LSB) must be less than or equal to 0x19998000.

So, if you change this line (Line 299):
to:
It should check the hash correctly. (The byte swapping on each of the 32 bit fields has been done for us already, but not on the array as a whole, so we start counting at the end which is 7 ; also keep in mind we're zero indexing)

For a difficulty of 50, i'd round off the threes
From:
00000000051EB333333333333333333333333333333333333333333333333333
To:
00000000051EB333000000000000000000000000000000000000000000000000

And simply check hash32[6] against 0x051EB333 instead of 0x19998000.
Similarly, for difficulty 100 i'd just check against 0x028F6000

Note that I don't much like byte swapping, and haven't tested my (one line of) code out, so you might want to get someone else to look over my logic here.

I'll read over the code for any more spots that might need modification in the morning.

(Hardest 1 BTC ever)

I had an in-depth discussion with alot of people in the chat and we came up with the conclusion that all it would do is be a lighter load on the shares validation and it would keep the bandwidth down.

Why would one want to change the difficulty level in pushpool anyways?

Let me clarify my OP. I know the config.c and how to set the target there. That's the easy one.

Now, open up msg.c and head down to the check_hash function, specifically the return of better_hash. It looks like it is checking a hard coded 40 bits of 0's. Won't I need to change this spot too? What should I change this to based on the 10, 50, 100 scenarios?

Then am I missing any other spots that would also need to be change?

Whenever I use rpcminer, it outputs a line like:
Target = 00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffff
Dunno if the other miners do. Anyway, if the target line corresponds to whatever you set in config.c, then it should be working.

Okay i tried this out, everything compiled fine, how do we know that its working? less shares being subbmitted?
UPloaded the compiled version to my official website just to test it out: www.miningfarm.com
it seems when i do this hashrate calculations goooo way down, but that could be because the formula i use is based of of Difficulty 1 maybe

In cfg.json, make sure "rpc.target.rewrite" is set to true:

Then in config.c, there's a line that says:

This is the target that the workers try to reach, stored in hexidecimal (higher target = less dificult).
Here is a basic overview of how to calculate the target.

Because difficulty = maximum_target / current_target, we can also say that current_target = maximum_target / difficulty

The "maximum" target (difficulty 1) is:
00000000FFFF0000000000000000000000000000000000000000000000000000
So, if we divide this by 10, we get:
0000000019998000000000000000000000000000000000000000000000000000
Which is the target at difficulty 10.
At 50 it's about:
00000000051EB333333333333333333333333333333333333333333333333333
At 100 it's about:
00000000028F6000000000000000000000000000000000000000000000000000

So simply copying this target into the quotes after #define EASY_TARGET will set the target to a given value. Note that by default it's easier than difficulty 1.

Edit: Obviously, after modifying the source of pushpool (including config.c) you need to recompile for the changes to take effect.