I think the pool.biblepay.org is definitely on a fork. I just updated my miners and checked with getblockhash to be on the "right" chain. Now I am at 99.99 % error percentage on the pool. Before (with some of them on the fork chain) I was at approx. 50%.
Someone is theorizing that the 75 tithe requirement is causing the fork. Previous builds did not require max 75 tithes in a block. Those versions that don't respect the 75 tithe limit (like exchanges on older versions) are on a fork. Looking at all the peers on the fork, there's a clear delineation. Older builds are on the fork and newer builds 75 tithe limit is like a mandatory but since not everyone is technically required to be on the latest version, consensus is not being reached.
I don't really know what to make of the comment, as my exec version report goes all the way down to 1191. Is it significant that 1189 is not on the list?
16:21:39 exec versionreport
16:21:39
{
"Version": "Popularity,Percent %",
"1191": "31; 15.12%",
"1192": "3; 1.46%",
"1193": "10; 4.88%",
"1194": "25; 12.19%",
"1195": "25; 12.19%",
"1196": "67; 32.68%",
"1198": "44; 21.46%"
}
No, that business logic rule for POG is not the cause of the fork; the memory pool requirements were leisures (they are soft business logic changes) that enforce the tx's before they have the 'ability' to be network/mined tx's -- but wont cause a fork.
I did analyze the particular block 105055 and it actually didnt have anything to do PODC or POG or superblocks; as a matter of fact MIP and I took a look at the chains that followed and what was very interesting is our hashpower basically split 50-50 and both chains were actually valid, but, there is something that happened to cause the First half of the network to originally mark 105056 bad (IE it marked it as bad, and it keeps a map of bad blocks) and we don't erase this until the core client actually physically erases the chainstate. We actually have code in place to recover (inherited from dash) but for some reason, it didndt work in this case. (I even tried to send sporks for an hour after 105055 to force the clients to reconsider 105056, and they failed). So thats why we all had to physically force ourselves back over to one main chain.
To prevent this in the future, Im not only going to Dashs latest Evolution, but also testing the fork commands in testnet to make sure that the wallet gracefully reorganizes when it hits a dirty block in the future - (something is just simply keeping it from auto-cleaning the dirty index), etc, so thats my top priority now to make sure this new Evolution version is completely fork-free.