An update on where I'm at with the share history checking I mentioned before:
https://bitcointalksearch.org/topic/m.23543194I've checked a sizeable amount of data from large miners, and all the blocks they report to have found in their own logging/miner stats, and all have indeed shown up correctly on the pool.
I've now written a fully independent share checker from scratch, not using (or even referring to) any code used in ckpool to do that at all, putting it in the KanoDB code, and will be running that on a backup server for all the shares in the past month to verify there's no lost blocks in the share data.
I don't expect to find any, but this luck has been bad enough that I need to check all the data in every way I can think of.
At this point it's to 100% verify that ckpool has indeed correctly processed the last month of shares that KanoDB has received.
Once I've got that running, I'll also add block submission to KanoDB, then I'll put it on the live server also - so in case it ever does find a block that ckpool missed, it will submit it anyway.
It will submit all blocks it finds, not just missing ones.
Turning on my conspiracy hat, there are more changes I'll be adding once I've started the month processing - which should be today some time.
I'll of course report anything I find in all this.
An update on this.
The share and block check/test of the full share log has been running on the backup server, and checking from block 482985 at the start up September.
It's so far it's up to checking the 8th of September, and has checked 16 blocks of data, with the same results as the pool code.
It should take about 6 more days to complete the test of 60 days of data.
It completely hashes from scratch, each share, and checks each share's calculated diff and makes sure it's the same, then also checks if it's a block.
It's part of the KanoDB code so I will put it on the live pool soon also.
But first I'm working on getting it to submit the blocks it identifies, so both the pool code and the KanoDB code submit blocks to their respective bitcoinds.
The block identification code I've written, uses the bit data from the work, thus does an exact check of the hash to identify if it's a block.
Here's the (not very useful to anyone
) small part of the new code that does that that I've written myself - not using anyone else's code at all.
Since I don't have a public git any more:
// check it's a block directly using the hash and bits
hex_to_bin_nonull(bin, sizeof(bin), wi->in_bits, BITSPOW<<1);
bits = *bin; // BITSPOW is 1 byte
hex_to_bin(bin, sizeof(bin), wi->in_bits + (BITSPOW<<1), BITSBASE<<1);
base = 0;
ptr = bin;
for (byt = 0; byt < BITSBASE; byt++)
{
base <<= 8;
base += (*(ptr++));
}
base &= BASEAND;
zeros = 32 - bits;
ptr = share_hash_bin + SHA256SIZBIN - 1;
for (byt = 0; byt < zeros; byt++)
{
if (*(ptr--))
return;
}
hash = 0;
for (byt = 0; byt < BITSBASE; byt++)
{
hash <<= 8;
hash += (*(ptr--));
}
if (hash >= base)
return;
// It's a block!
LOGWARNING("%s() BLOCK %"PRId32"/...0000%06x sdiff %.3f ndiff %.3f",
__func__, wi->height, hash, sdiff, wi->diff_target);
I'm today working on adding block submission at this point in the code, then add it to the database if it's not already there also, then I'll run it on the live pool,
then get back to working on the accounting code ...
