I like your idea, about adding the 12th element, the biblehash directly to the x11 algo. But for now, I have already created a testnet version where we lower the X11 component by 300%.
On a side note, I am potentially setting the mandatory for block 7000, to give time for ccex. (And also, in case we can squeeze in the txindexlookup system in PoBh to raise the bar even further before block 7000 hits).
The testnet version should be ready by block 1350 - but Windows will take the rest of the day to compile.
In the next testnet version, we lower the x11 difficulty by 300% as of block 1350, thereby putting the onus on PoBh.
Im testing this now; will let you know when linux is ready as Ill need help testing this in testnet.
That's some fast work
Looking forward to testing this, I'm hoping it'll solve a lot of the issues we've been experiencing.
I was thinking a little more on the possibility of a hybrid GPU miner. Even if all the difficulty was loaded onto the Biblehash algorithm, if the GPU mined a batch of X11 solutions, sent those to the CPU to be processed, then mined the next batch while the CPU was working, it might still provide an advantage?
I'm very interested in seeing some metrics on X11 and Biblehash. If we assume that after the update there's exactly one X11 hash for every Biblehash iteration, and Biblehash requires 1000x as many cycles as X11, you'd get at most a 0.1% performance gain (realistically less, reading back from a GPU is slow). Obviously, in that case there'd be absolutely no point in doing this and you'd be better off CPU mining Biblepay and using your GPU for something else. If, however, the metrics aren't quite that lopsided, it might be a different story.
Of course, it might start begging the question at some point about why include X11 if it contributes so little to overall mining process. I think it still makes sense, though, since it adds a lot of complexity to any attempt at creating a Biblepay GPU or ASIC miner beyond the obstacles posed by Biblehash itself. ASICs especially, since complexity is directly tied to manufacturing cost.
Just got back in, so I agree primarily with everything you say, and I recall going back to the original miner, I used the x11 hash value as an input for the original biblehash, because it was a reliable strong distinct blockhash; my fear was, with business logic going into the biblehash itself (as we raise the bar), there are conditions where the biblehash could possibly return the same value for two blocks (or worse, a faulty hash if someone was not synced), and I wanted to make sure the blockindex would stay safe. Otherwise, I would have completely switched out the x11 algo with the biblehash. Im glad we did, so now we can put some business logic in the PoBH area (like the tithe rule and tx lookups).
Anyway, yes, Im all for removing the x11 from the POW.
Btw, whoever compiled the latest and is trying to test with me in testnet, please do a get on the 1021c; the version had two required changes and I just checked it in.
So, now our newest version eliminates x11 from the miner in testnet after block 1350, and keeps x11 for blockindex references, and uses 100% of the PoBh for POW in the miner.
(This way, we wont risk breaking the blockchain storage, txlookups, and all the places that rely on a block->GetHash. Yet the security is still there because the POW of each block is protected by the biblehash output).
Lets see how this behaves in testnet, the new version is out (for testnet only). Re-building windows now.
I've added another miner for comparison, and all three now report a KHS that is consistent.