|
Title: mining.notify not as expected Post by: michaelIP on July 07, 2019, 08:02:26 PM Not sure if this is the right forum, first post. Please redirect if necessary.
I have used tcpdump to look at the rpc traffic from 2 different BTC pools to one of my S9's and find that the mining.notify data is not what I expected. mining.notify contains the following fields job ID previous block hash coinbase 1 etc... coinbase 1 has embeded within it the current block number being mined. So... I have captured the mining.notify from 2 different pools, 3 different blocks as show below. The previous block hash sent in the mining.notify string. The actual previous block hash found using the blockchain.com block explorer. In each case, there were no blocks found between the time the sample was taken and when the next block was found. The third sample actually overlapped the finding of the block and the block was found by the sampled pool (Viabtc) Note: mining.notify string is bytewise reversed for comparison to block explorer value 562087 mining.notify 00000000000000009e941400689b3885952ddf6f748976d233878a1791bb6a58 block explore 00000000000000000014949e85389b686fdf2d95d2768974178a8733586abb91 568798 mining.notify 000000000000000014b83e00dde48af647d5c4c9a8a42b3dad157be5d6103f12 block explore 0000000000000000000a90fd6cf2c6796756bbfd224475cf24ca9bfd6b183dc1 584034 mining.notify 0000000000000000ad5601009f6dccd0feb624bb7f2389326f17decfe3aedec4 block explore 0000000000000000000156add0cc6d9fbb24b6fe3289237fcfde176fc4deaee3 It was my assumption that the previous block hash (a block already found) would be immutable. In addition, the block explorer says that the mining.notify values are "not found" in any blockchain. What am I missing? Can someone shed some light on this for me? I do not see how it is possible for the miner to calculate a valid hash solution when the PBH is not the value that is in the final block hash solution. |