Koooooj
Member
 Offline
Activity: 75
Merit: 10
|
 |
July 18, 2013, 02:20:02 AM |
|
For the process of submitting data to primecoind, I would reference the submitBlock function in the same file on line 346. Critical to that function is the parseHex function, which converts the parameter from a string to hexidecimal (i.e. the string "10c8e" would become the number 10c8e or 68750 in decimal), the constructor to the CDataStream class, found in serialize.h, and the ProcessBlock function found in main.cpp (line 2236).
From the looks of it the parseHex function is just a simple utility function and the ProcessBlock function just goes through and makes all the appropriate checks to prevent DoS attacks and to make sure the block is valid. The real magic of submitting the block is in getting the right hex data, in the right order. For that, I would look at how CDataStream interacts with CBlock, as the former is just a holding cell for the latter (hex data is put into the CDataStream and then fed into the CBlock object, as is shown on line 359 of rpcmining.cpp. CBlock is defined on line 1340 of main.h.
The relevant function is defined on line 1362 (IMPLEMENT_SERIALIZE), although it is defined by macros. Looking at these macros (defined in serialize.h, lines 55-93) it would appear that you first must give the block header, followed by a vector of transactions. The block header is defined in main.h on line 1266 and should have the following fields in order: Version, previous block hash, hash of the Merkle root, time, "nBits" (the target, defined in prime.cpp), the nonce, and finally the prime chain multiplier (i.e. hash * multiplier = origin of the prime chain). Each item in the vector of transactions should contain, in order: Version, a vector of inputs (CTxIn), a vector of outputs (CTxOut), and finally "nLockTime" has minimal documentation but it says it was implemented in (presumably Bitcoin) version 0.1.6.
This hierarchy continues, where each object that has data members that are, of themselves, objects, until you get to the point of primitives. CTxIn, for example, has COutPoint prevout (object), then CScript scriptSig (object), and finally nSequence (an integer--primitive). The order is seen for these on line 347 of main.h as the order of the READWRITE lines. One can go deeper by finding where COutPoint and CScript are stored and looking at their READWRITE definitions in IMPLEMENT_SERIALIZE.
When one finishes crawling this tree of IMPLEMENT_SERIALIZE functions you get to the point where you have a really long sequence of data that must be submitted. If you collect all of that data in the right order, represented as its hex values and you pass it to the submitblock function (e.g. primecoind submitblock <data>) then it will go about checking to make sure that the prime chain is long enough and, if it is, it should broadcast it through the network.
For the process of getting data from primecoind, I would reference the getwork function in rpcmining.cpp on line 86. Based on its documentation it seems that it should return formatted hash data to work on. However, every attempt I've made to run "getwork" on my windows QT machine has resulted in the client crashing. On linux, on the other hand, it nicely returns midstate, data, hash1, and target as separate fields in a JSON format (similar to the output of getmininginfo, but with different fields). I believe that hash1 and midstate are not needed and are holdovers from the Bitcoin roots of the client. Target is the difficulty, although its format is a little bit odd (it is little-endian, which means that the least significant digit is first. Data is a 128 byte array that contains the hash of the version, hash of the previous block, hash of the Merkel root, the time, the difficulty, the nonce, "block", and hash1. I believe this is the order that the data is listed, and I believe that this is sufficient data to find the hash needed for the proof of work (if one of the hashes already contained isn't already the hash needed).
I've exhausted my skill (at least until I can get some sleep) as far as looking at the getwork and submitBlock commands are concerned. There's plenty of fun C/C++ tricks going on and I only hardly know C/C++. I hope that this is useful towards the development of a GPU miner. If you're feeling generous and this helped, I can receive donations/bounties at (BTC)1FbWVR3LpGoWp5rc4SJc3cHo42ALrYhcxC or (XPM) AFozUk53j5uZCrKAhkcrM6SjnKtGRXCnov. I will, of course, attempt to answer any questions about this, although all I know is what I've read and this is a much larger project than I've ever worked with.
|
