Show Posts
|
Pages: [1]
|
You seem to be right. I have submitted a pull request for Jeff Could you submit another one (I'm pretty new to CVS, and have sadly too little free time to dig in)? cjson_encode(), server.c: 233 /* fill in compressed length */ 234 *obj_clen = htole32(comp_len); It's little mismatched with whole idea. Instead of comp_len, unc_len should be there. Must be too late in night, when this part was written.
|
|
|
Turns out it was server-side bug. In cjson_decode() function located in server.c unpacking code contains following lines: 176 /* decompress buffer (excluding first 32 bits) */ 177 comp_p = buf + 4; 178 if (uncompress(obj_unc, &dest_len, comp_p, buflen - 4) != Z_OK) 179 goto out; 180 if (dest_len != unc_len) 181 goto out; 182 memcpy(obj_unc + unc_len, &zero, 1); /* null terminate */ This call of uncompress() isn't completely correct according to zlib docs. dest_len should contain actual size of buffer for uncompressed data before calling uncompress(), but it's never initialized. This should be corrected (e.g. dest_len = unc_len + 1).
|
|
|
You send following json to server if you need data to work on: {"method":"getwork","params":[],"id":"json"} Sever responds with: { "id":"json", "error":null, "result":{ "midstate":"0e8a0e8d83ae508c1a0859c3a298d86676904b83803ac67323ed2c51d8e2d7f3", "target":"ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000", "data":"00000001cddc2362bc4b15ef5ebf6fef9dd58bcb24ca1f05596bcd9e0000078400000000f5354d24f29a46e2c1ecf861795ffe4f26ee7cc0755098b2421dc823b42b16264e0b78c41a0c2a1200000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000", "hash1":"00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000" } } Is block data just the header? It's header in big-endian hexademical format with additional bytes for SHA256 (see wiki on SHA256 for details). When a miner hits the target, how does it send the nonce back? Same getwork reqeuest as first one in this post, except params isn't empty and has work-data with valid nonce. In hexademical big-endian ofcourse. See source code of any miner for more details.
|
|
|
uncompress() actually returns Z_BUF_ERROR indicating the output buffer was too small. I don't understand how it can be since server allocating uncompressed_length + 1 bytes which obviously enough.
I'm pretty sure that sent uncompressed_length is correct.
|
|
|
By printing out some debug info I've find out that's problem is uncompressing on server-side. I'm trying to do the following using Qt-built-in zlib ( highlighted version): char json[] = "{\"version\":1,\"user\":\"test\"}";
std::auto_ptr<Bytef> message(new Bytef[ // allocate memory for: sizeof(ubbp_header) // + ubbp_header + sizeof(uLongf) // + uncompressed length + strlen(json) // + message + SHA256_DIGEST_LENGTH // + sha256 + 64]); // + reserve (if compressed size > uncompressed size)
uLongf unc_len = strlen(json); uLongf comp_len = unc_len + 64;
Bytef* pHeader = message.get(); // header Bytef* pLen = pHeader + sizeof(ubbp_header); // length of uncompressed data Bytef* pCompDat = pLen + sizeof(uLongf); // compressed data Bytef* pSha256; // digest
if (Z_OK != compress2(pCompDat, &comp_len, (Bytef*)json, unc_len, 9)) { qDebug("Compression failed"); return false; }
/* calculating message digest */ char pass[] = "test"; uchar md[SHA256_DIGEST_LENGTH]; SHA256_CTX ctx; SHA256_Init(&ctx); SHA256_Update(&ctx, pLen, comp_len + sizeof(uLongf)); SHA256_Update(&ctx, pass, strlen(pass)); SHA256_Final(md, &ctx);
/* building message */ uLongf msg_len = sizeof(ubbp_header) + sizeof(uLongf) + comp_len + SHA256_DIGEST_LENGTH; header.op_size = UBBP_OP_SIZE(BC_OP_LOGIN, msg_len - sizeof(ubbp_header));
pSha256 = pCompDat + comp_len; memcpy(pHeader, &header, sizeof(ubbp_header)); memcpy(pLen, &unc_len, sizeof(uLongf)); memcpy(pSha256, &md, SHA256_DIGEST_LENGTH);
/* sending message */ socket.write((char*)message.get(), msg_len); socket.waitForBytesWritten(); And still server-side uncompress() (located in cjson_decode()) doesn't returns Z_OK. Where's mistake?
|
|
|
Developing pushpool clientHello, I'm really interested in jgarzik's pushpool (it's binary protocol in particular) and writing Qt-based client. Problem is that I can't make it through LOGIN step. As far as I undestand from forum's threads and (mostly) pushpool's source code, I need to send ubbp_header with BC_OP_LOGIN operation code and message's length in bytes. Message is SHA256 of compressed json updated with userpass following compressed json. Json looks something like this (protocol is always 1, config is always null): {"protocol":1, "user":"username", "config":null} And I'm doing following ( higlighted version): ubbp_header header; strcpy((char*)header.magic, PUSHPOOL_UBBP_MAGIC);
QSocket socket; socket.connectToHost("my.pushpool.host", 8336); socket.waitForConnected();
// add compressed json to data dataToSend = json.toUtf8(); dataToSend = (qCompress(dataToSend, 9));
// Since qCompress() adding length (first 4 bytes in dataToSend) in Big-Endian, // but server uses le32toh() to get it, change endianness to Little-Endian: dataToSend.remove(0, 4); uint32_t len = json.length(); dataToSend.insert(0, (char*)&len;, sizeof(uint32_t));
// add compressed json digest char pass[] = "test"; uchar md[SHA256_DIGEST_LENGTH]; SHA256_CTX ctx; SHA256_Init(&ctx;); SHA256_Update(&ctx;, dataToSend.data(), dataToSend.size()); SHA256_Update(&ctx;, pass, strlen(pass)); SHA256_Final(md, &ctx;); dataToSend.append((char*)md, SHA256_DIGEST_LENGTH);
// Send operation code & message size header.op_size = UBBP_OP_SIZE(BC_OP_LOGIN, dataToSend.size()); socket.write((char*)&header;, sizeof(ubbp_header)); socket.waitForBytesWritten();
// Send message socket.write(dataToSend); socket.waitForBytesWritten();
// Here's a problem: // after message sent, I get // QAbstractSocket::error() with 'Remote host closed connection' My assumptions: - JSON compressed by qCompress() cannot be uncompressed by zlib (even after my manipulation)
- I'm calculating wrong SHA256
- Something wrong with json (i.e. config must not be null)
After puzzling for almost whole day, I'm writing here. Guys, please help.
|
|
|
Hello, I've been reading this forum for last month. I haven't registered yet, since "read-only-mode" was more than enough. But now I've faced a problem that only question in Development board could solve. It's about jgarzik's pushpool and it's binary protocol. I'm writing Qt-based client, which can't get through LOGIN step. I've been puzzling whole day and still no result. I belive someone in dev-board can help me to figure out what's wrong with my code. Obviously, i can't help myself out using newbie's forum, so please whitelist me.
|
|
|
|