Author

Topic: A newbie wants to understand the bitcoin mining concept (Read 1245 times)

full member
Activity: 172
Merit: 100
Maybe a c64 cluster would be a solution... Smiley

Maybe if you get all c64 ever sold in your cluster..  Grin
legendary
Activity: 965
Merit: 1000
Uh....not really... Smiley

I just write some code and want to keep it portable, so compiling it for the c64 is a good test.

Problem is the poor performance of the old breadbox. It computes about 2 hashes per second at the moment... Sad

Maybe a c64 cluster would be a solution... Smiley

But exactly the same code without any modifications, 32-bit optimizations, multithreading etc. computes about 2 million hashed on my Ahtlon 840 3,2 GHz.

My actual target platform are cheap GPUs. Older NVidia cards and such. Maybe the idle times of such machines could be used for a low performance pool, or so...

Ciao,
Andreas
hero member
Activity: 1596
Merit: 502
You are going to mine bitcoins on a commodore 64 ??
How cool!  Grin
legendary
Activity: 965
Merit: 1000
Since the hashes are declared as uint8, you should see it as unsigned, so no they will never be negative.


Thanks...I was just confused about the difficulty, since the wiki says it's signed...
full member
Activity: 203
Merit: 122
Gir: I'm gonna sing the Doom Song now..
Since the hashes are declared as uint8, you should see it as unsigned, so no they will never be negative.
legendary
Activity: 965
Merit: 1000
The current code is available here:

http://www.forum64.de/wbb3/board25-coder-unter-sich/board308-programmieren/board29-cross-development/45342-bitcoin-mining-auf-dem-c64/#post579246

At the moment, it's just a hack to get something going. The sha256 code is a mixture of some implementations, found at various place of the net. Some of it is from Christophe Devine, but I couldn't use the optimized code with the unrolled loops due to memory constraints. The Makefile does no real speed optimization yet, since I wanted the code to be optimized for size and not speed.  The networking part is completely missing yet, but I doubt if it makes sense to request actual blocks, since the breadbox is just too slow for productive work (100 nonces in 274 seconds at the moment).

Ciao,
Andreas
legendary
Activity: 965
Merit: 1000
Thanks a lot for your comment. I had the option of a negative difficulty in my code, because the wiki said, that it's a signed value. From a practical point of view, a negative difficulty doesn't make much sense, so I will fix my code.

Thanks again for your reply,
Andreas
hero member
Activity: 1596
Merit: 502
You now look at the 32 byte integer as if it is a signed integer but it should be an unsigned 32 byte integer.
legendary
Activity: 965
Merit: 1000
Hi!

Sorry for my poor Englisch, but it's not my native tongue, since I'm from Germany.

I have read about the bitcoin concept a while ago and already installed a miner on my Radeon 5850. Works ago, but I'd like to get a small miner going on my daily coding machine, which has a GeForce 7. So I got me BrookGPU, got some demo apps going and want to write some code for it.

Since I have not much clue about the whole mining process, I thought that I should start with a very simple demo app, called hashcode and modify it to do something useful. So I ported it to the cc65 compiler and run it on Vice (a c64 emulator) just to have some fun with it and to understand the code etc.

My current problem is the difficulty <=> hash comparison. I wrote a decode function for the difficulty according to the Wiki entry:

Code:
/**
 * Decode the target into a 256 bit int. See the target entry in the bitcoin wiki for details.
 */
void decodeDifficulty( uint8 *targetArray, uint32 target) {
  uint32 offset = ( ( target >> 24) - 3) << 3;
  int bitshift = offset & 7;
  int currentByte = offset >> 3;
  uint32 targetBits = target & (uint32)0x00ffffff;

  if( targetBits & 0x00800000) {  // Is the difficulty negative?
    targetBits |= (uint32)0xff000000;
    bzero( targetArray, sizeof(uint8) * currentByte);  // Empty everything below the bitmask
    memset( &targetArray[ currentByte + 4], 0xff, sizeof( uint8) * ( SHA256_DIGEST_LENGTH - 4 - currentByte));  // Fill bits over the bitmask with 1 for sign extension
  } else {
    bzero( targetArray, sizeof(uint8) * SHA256_DIGEST_LENGTH);  // Empty the target array
  }

  targetArray[ currentByte++] = (uint8)( targetBits & 0xff);
  targetBits >>= 8;
  targetArray[ currentByte++] = (uint8)( targetBits & 0xff);
  targetBits >>= 8;
  targetArray[ currentByte++] = (uint8)( targetBits & 0xff);
  targetBits >>= 8;
  targetArray[ currentByte] = (uint8)( targetBits & 0xff);
}

and a compare function for 32 byte integers:

Code:
/**
 * Compare 2 256 bit integer values.
 *
 * @return a value > 0, if hash1 > hash2 , a value < 0, if hash1 < hash2 and 0 if they are equal.
 */
int compareHash( uint8 *hash1, uint8 *hash2) {
  uint8 msb1, msb2;
  int currentByte;
  int byteDifference;

  // Check, if both numbers have the same sign..
  msb1 = hash1[ SHA256_DIGEST_LENGTH - 1] & 0x80;
  msb2 = hash2[ SHA256_DIGEST_LENGTH - 1] & 0x80;

  if( msb1 != msb2) {  // Both numbers differ in sign
    return msb1 ? -1 : 1;
  }
 
  // We have to compare byte by byte... :-(
  for( currentByte = SHA256_DIGEST_LENGTH - 1; currentByte >= 0; --currentByte) {

    byteDifference = hash1[ currentByte] - hash2[ currentByte];  // Compute the difference of the current bytes-.

    if( byteDifference) {     // If the bytes differ.
      return byteDifference;  // just return the difference.
    }
  }

  return 0;  // both ints are equal.
}

, but what happens if the hash is greater then 0x8000.... => is negative? It's smaller in my current code, so it would be a solution, which is wrong as I understand it. So should I compare abs(hash) < difficulty ?

Thanks in advance,
Andreas
Jump to: