Topic: [BOUNTY] Pushpool question - page 2. (Read 7875 times)

Oh I see, that makes sense.

The answer is that I don't compute the block number.

I don't think there is something like a block ID, there can be multiple blocks at a point of time with the same height (same previous block) and (theoretically) multiple blocks with the same hash. Theoretically it's also possible, even if tremendously unlikely, to have different blocks, at the same height, and having the very same hash.

I wondered about how finding about it though, didn't find a satisfying solution and ended up dropping this issue altogether since I don't really need it in my context.

Please someone correct me if I'm wrong but I think the only way to get the block number without relying on an external service is to simply maintain a linked list of the whole block  chain's headers starting from the genesis block and count the items of the list.

Yes, I understand that part.

Sorry, I think I was confusing - I'm new to this and was just wondering how you personally going about getting the block number. I've since worked out that different people seem to have different "counts" on the block number - some people starting from 0 and some from 1.

When I say block number, I don't mean the hash. I mean the number.

Certainly not, the block hash is derived directly from the share solution, see the class I pasted.
Basically you initialize a BlockHeader object, feed it the share solution, from there it gives you accessors on the various block header properties (prev. block hash, timestamp, nonce etc.) and an accessor on the block hash.

You can do :

And this doesn't hit any external service

Obviously you can get it from : http://blockexplorer.com/testnet/rawblock/

But, is there a better way ?

Thanks for this, it's excellent.

Can I ask what method you are using to convert your solution, or your block_hash into the block ID?

Here we go, if anyone is interested in the ruby BlockHeader class.

Not very elegant, but it does the job :
 - Extracts block header fields
 - Computes block hash

http://pastebin.com/y0sMZSbi

Thank you very much

You may also find python hash checking source code, well documented for analysis:

https://github.com/jgarzik/pyminer/blob/master/pyminer.py Miner.work()

http://yyz.us/bitcoin/poold.py checkwork()

Hey !

thanks for all the input !

I found this piece of code, it's been really useful, now I manage to decode the block header and extract the different fields, I don't think it's a necessary step to retrieve the 2xSHA256 checksum but I just felt it would help my understanding. Thing is I'm doing something that shouldn't work, yet it somehow works... I can't get my head around it.

So for example, to retrieve the previous block hash from the block header I thought I would have to do this :
 - Chop the string between position 8 and 8 + 64 to get a hex representation of the previous hash in little endian
 - Swap bytes to retrieve big endian representation

So, to swap bytes I first tried to reverse the string with chunks of two hex chars, "ab cd ef gh ij kl mn op" becoming "op mn kl ij gh ef cd ab". Didn't work out well.
But for some reason I don't understand, doing that in chunks of 4 bytes (8 chars) yielded correct results ("ab cd ef gh ij kl mn op" -> "ij kl mn op ab cd ef gh")

Looks pretty straightforward in the example code (which yields correct results btw when I hardcode my data sample) :
 - Take previous block hash in big endian
 - Swap bytes without chunks
 - Hash along with the rest of header data

My code (missing the checksum part, and mysteriously succeeding at extracting merkle root and previous block hash) : http://pastebin.com/yVvvwRUd

http://pastebin.com/Ya3604J0
I found this code which takes some information and calculates the checksum of the blockheader. It should be possible to use this code to read the hash of the previous block.

It is as sipa said...  This is not a custom format.  pushpool is recording the 'getwork' data sent from the miner client, verbatim.  That is standard across all of bitcoin.  The first 160 hex chars (80 bytes) are the block header that successfully found a solution.

To link that to a block, the block header includes the 'prevhash' field that tells you precisely block X-1, for solved block X.

This is pretty frustrating,  

I'll pay 3 BTC to the person providing a Ruby solution (or that helps me code a working one )

EDIT : Maybe there's something to do with endianness ?

Maybe I'm doing something wrong but it doesn't really seem to work ...

The original solution :

I strip it down to the 160 first chars

I pack it to a binary string :

Hash it a first time

Then a second time

And then finally unpack the result back to hex

Doesn't match the block hash...

I feel like a total clueless noob on this one

Any ideas ?

Thanks a lot! I'll try that and post the results.

That looks like a hex-encoded block header, including padding done by the sha256 hasher.

Take the first 160 characters of it (80 bytes), decode each group of 2 characters as a hex to a byte, and feed those 80 bytes to a regular sha256 hasher, twice. That should give you the block's id.

No one ?

TL;DR : Share solutions, how do they work ?

I've installed jgarzik's pushpool and it's successfully running against a bitcoin client running on testnet,

Pointed a miner at it, generated a few blocks, now I need to track them, and link them to the share that provided the right solution.

So I have a share where pushpool's result is "Y", upstream result is "Y", seems like it generated the block http://blockexplorer.com/testnet/block/000000000055825d01acc3dcc80d02671c2e75ab5b692940446e9b8615ea3824

I do own the address and the logs show a share submission time that is the same as the block timestamp.

The recorded solution for the share is
and the block hash is
So my question is, how do I get to the block hash from the submitted share solution so I can track these properly ?