Bitcoin Forum
June 28, 2024, 06:49:21 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 [6]
101  Other / Beginners & Help / Re: What Do You Use Bitcoins for? on: February 22, 2013, 12:44:24 PM
I have bitcoins in my pocket and feel good about it.
102  Other / Beginners & Help / Re: Introduce yourself :) on: February 22, 2013, 12:42:38 PM
Hello, bitcoin is very interesting.
103  Bitcoin / Mining software (miners) / Re: python OpenCL bitcoin miner on: April 13, 2011, 07:16:36 PM
Quote from: m0mchil on April 12, 2011, 04:49:48 PM
No. The kernel computes correctly only the 4 first bytes. It's confusing, because there is a code in BitcoinMiner.cl BelowOrEquals() which checks 8 bytes - this produces better assembler for some reason, at least in my setup. It can be replaced with 'if (H == 0)' (but it was slower). That's exactly why the targets are hard coded to difficulty of 1 (00000000 FFFF0000).

If you mean that this:
Code:
#ifdef VECTORS
	if (belowOrEquals(H.x, targetH, G.x, targetG))
	{
		output[OUTPUT_SIZE] = output[nonce.x & OUTPUT_MASK] = nonce.x;
	}
	else if (belowOrEquals(H.y, targetH, G.y, targetG))
	{
		output[OUTPUT_SIZE] = output[nonce.y & OUTPUT_MASK] = nonce.y;
	}
#else
	if (belowOrEquals(H, targetH, G, targetG))
	{
		output[OUTPUT_SIZE] = output[nonce & OUTPUT_MASK] = nonce;
	}
#endif
}
is faster than this:
Code:
#ifdef VECTORS
	if (H.x == 0)
	{
		output[OUTPUT_SIZE] = output[nonce.x & OUTPUT_MASK] = nonce.x;
	}
	else if (H.y == 0)
	{
		output[OUTPUT_SIZE] = output[nonce.y & OUTPUT_MASK] = nonce.y;
	}
#else
	if (H == 0)
	{
		output[OUTPUT_SIZE] = output[nonce & OUTPUT_MASK] = nonce;
	}
#endif
then I got very different results in my tests on Windows 7 x64 & HD5850.

With belowEquals I get ~270Mhps
With the H == 0 version I get ~275Mhps

That's a 1.8% speed increase.

Quote
Actually you are right, but in a different way - because of this I should use hard coded kernel target of 00000000 FFFFFFFF in order to not lose 1 thousandth of a percent of all valid difficulty=1 candidates. I'll do this with the next release.

I'd just stop the target from being sent to the GPU and do that H==0 thing. I see no logical reason that it would be slower. There might be illogical reasons, though :-)

Quote
Why you check for 'lower' with a 'greater than' operator? Where did the '0x80000000' came from?

I guess I didn't explain that part that well. I chose 0x80000000 to make it easy to determine if bytes 4-7 were actually calculated correctly. I edited BitcoinMiner.cl to only accept hashes below 0x80000000. In the Python code, "> 0x80000000" (should've been >= though) is checking if that part of the hash is over 0x80000000 and warns the user if it is, i.e. if the GPU calculated the hash wrong. But none of that matters since it wasn't even supposed to calculate bytes 4-7 right.
104  Bitcoin / Mining software (miners) / Re: python OpenCL bitcoin miner on: April 11, 2011, 06:43:25 PM
I think I've found a bug in poclbm. If I'm right, it goes like this:

The OpenCL part is supposed to calculate the 8 first bytes of the hash. The 4 first bytes are calculated fine, but the next ones are not, so they end up being essentially random numbers. In specific situations, it could lead to the miner ignoring a valid block.

In the python code:
BitcoinMiner.py:161
Code:
				if h[7] != 0:
					self.failure('Verification failed, check hardware!')
				else:
This part checks that the first 4 bytes are indeed zeros. I added another check.

Like this:
Code:
				if h[7] != 0:
					self.failure('Verification failed, check hardware!')
				elif h[6] > 0x80000000:
					self.failure('Verification 2 failed, check hardware or the algorithm! :-P')
				else:

Then I made another change.

BitcoinMiner.py:273
Code:
			self.miner.search(	queue, (globalThreads, ), (self.worksize, ),
								state[0], state[1], state[2], state[3], state[4], state[5], state[6], state[7],
								state2[1], state2[2], state2[3], state2[5], state2[6], state2[7],
								pack('I', uint32(0xFFFF0000)), pack('I', 0),  #<-- here's the target
								pack('I', base),
								f[0], f[1], f[2], f[3], f[4], f[5], f[6], f[7],
								output_buf)
I saw the target given to OpenCL is hardcoded. I changed 0xFFFF0000 to 0x80000000. That should cause the OpenCL part to return nonces that result in hashes having the first 8 bytes lower than 0x0000000080000000, right?

Turns out it doesn't. When I ran poclbm, I got the "Verification 2 failed" message in a few minutes.

For some reason, there is commented-out code in BitcoinMiner.cl that modifies G, which should be the bytes 4-7 of the resulting hash in the end.

BitcoinMiner.cl:299
Code:
	//W13 = W13 + (rotr(W14, 7) ^ rotr(W14, 18) ^ (W14 >> 3U)) + W6 + (rotr(W11, 17) ^ rotr(W11, 19) ^ (W11 >> 10U)); 
	//C = C + (rotr(H, 6) ^ rotr(H, 11) ^ rotr(H, 25)) + (B ^ (H & (A ^ B))) + K[61] + W13; G = G + C;

	//G+=0x1f83d9abU;

Uncommenting them didn't fix the problem, though.

Why is this a problem, then? If the bytes 4-7 of the real hash are below the current target, but the OpenCL program calculates that they're over the hard-coded value of 0xFFFF0000, it would lead to a valid block being ignored, and no BTC for you.

Proposed fix: As the bytes 0-3 are calculated correctly and the target given to OpenCL is hardcoded anyway, I'd drop the target being sent to OpenCL altogether and have it just report nonces that lead to hashes for which the first 4 bytes are zero.
Pages: « 1 2 3 4 5 [6]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!