Just started a VM to try it and I also managed to get different biblehash!
Note: The mn4 machine above is running OpenSSL 101t while this one is running OpenSSL 102g
}
root@snapshot-7903-unknown-4gb-fsn1-1 ~ # biblepay-cli exec biblehash e0118ac9c4b5f6ec508e4bfefc38599fd55e7f79d108a560aeff9ceb0debc347 1510892191 1510890756 17074revheight 17111.000000 pindexPrev 20e9f4416b8e469b23a6fde82f197342086622e9ac827e78875701d001ca3916
2017-11-17 10:05:14 ERROR: CheckBlockHeader(): proof of work failed
2017-11-17 10:05:14 ERROR: ProcessNewBlock: CheckBlock FAILED
2017-11-17 10:05:14 Misbehaving: 97.99.69.33:40000 (0 -> 5)
2017-11-17 10:05:14 UpdateTip: new best=541a323bbf91103d90556af0e5b9143673a2cd36680fffe21bc3b7a9cbc85356 height=17112 log2_work=57.818294 tx=28819 date=2017-11-17 10:05:12 progress=1.000000 cache=0.0MiB(112tx)
Nice tests, thanks, you really gave a lot of data to work with and pretty much every condition LOL.
So Im going to make this my top priority today.
On your question about re-running the biblehash command with a prior blocknumber parameter (the ones you noted 17069, same as 17079) etc, that is fine because the block number parameter being sent into the biblehash is only used for it to determine the chain height, to turn on or off f7000 or f8000, and that is enforced on all nodes so that is secure, so changing that between f7000 start and f8000 start will just give you the same exact biblehash, so that is OK. Changing the lastblocktime is a similar issue: that only drives when the block becomes "late". When the block time exceeds 30 minutes then and only then the hash changes, so that is OK too.
On the question regarding the if statement, which hash its using, in this last version 1060, it is actually checking both, first it says if biblehash1 is too high, then if biblehash2 is too high, so your log only yields errors where they both were high hashes. But thats OK too, because you still exposed enough information.
However I wasnt sure if you had to run the cli command 10,000 times programatically to change the hash in your example because I ran one of your examples 125 times from my RPC and received the same hash every time so so far I have been unable to change the hash like you have, but dont worry, I have enough info from your log for something to go on.
But focusing in on the one where you show that the hash1 and hash2 are actually completely different now that is the big dog right there, that is the smoking gun, I have never seen that. Imo, that rules out the math operator and math class, that was generated on 101t, so it "points" toward not being openSSL versioning, it really points to either the MD5 function 'caching' the prior result (from the last blockindex check), or the AES512 vector 'caching' the last result. So I think today, Im going to hone in on making an alternate (compatible of course) biblehash, using a different md5 supplier and refactoring the AES512 call, and we can run that side by side, and see if something changes.