So Ive been researching the difference between X11 and F7000 and have uncovered some more info related to HPS consistency across all processors platforms and instance counts.
Some of you have really been hard on me, especially those who cant grasp the distinction between a "node level mutex" and a "processor" mutex. You even went as far as to say the BibleHash itself is inconsistent. One thing Ive learned over 30 years in software, is nothing about a computer or its software is inconsistent. (Unless someone puts a rand() statement in the code). Another words, every "hard" problem that Ive seen over the years, in the end, always has a very clear reason.
Let me explain the difference between a node mutex and a processor mutex. A node mutex is one where an instance of the software is forced to wait somewhere in the
*instance* of a program for a memory space to be available. A processor mutex is one that consumes the entire processor and it does not have to wait except for new work, and the entire server is frozen in what appears to be a locked state (btw, a crash is very different than a consumed processor).
So with BiblePay, with Pre-F7000, we had a processor mutex, in the sense that one had to buy more hash power to hash against the money supply. With F7000, the goal was originally more of a much stronger line of defense against GPU porting, hence the reason we added the node mutex. Ill stop here and explain. There are two places in BibleHash that are extremely hard or impossible to run on a GPU: asking the node to go back in the chain for a block index hash, or for example a transaction hash. Since the node level instance stops hashing while it waits for the data, the other mining threads slow down. Otoh, if you run multiple degraded instances on one server, you have parallel stops. However, what I dont like about that is it encourages low quality instances whereas I believe it is healther for us as a community to have higher quality instances.
So in light of this, the basic explanation is that F7000 does do its job in preventing BibleHash from running on a GPU, but it promotes the user to run as many low quality nodes as possible to squeeze as many BBP per hour from our community.
I think the answer to this is during the Christmas update (Sanctuaries), we release F8000 with a few more enhancements to fix the problem (we can test these in testnet as soon as available). #1: Add a math problem to BibleHash. This would force the processor to execute a few hundred K of instructions deterministically but unknown at the time of the hash (IE Block hash + timestamp hashed) so no one can predetermine the problem, and this solution would be similar to executing N X11's hashes for a second or so, thereby changing the state of the nodes miner back to a processor mutex level, thereby solving the degrading network problem.
The other thing I would like to introduce before Christmas update is making mining more of a privilege. I was thinking, instead of asking BiblePay to pay you simply because you plug a computer in and *want* to hash, what if BiblePay wants you to contribute to the community? I was thinking at the very least, the node will somehow need to ask the miner to Repent for sins and make a blog of progress. Maybe we make the mining software require a Repentant sin in the block, (IE Think of the 40 mortal sins listed in Send Money (in the wallet) | check Repent | Look at the dropdown values), maybe each week, the miner must repent of a sin, and describe how they are doing in their walk of repenting for sins in the message. If no repentance is being given, no mining is awarded. But each week, either a new description in the walk of a sin free life must be added, or - a new sin to be worked on, this way we can hash the repentance information and ensure it is changing once every 7 days (this way, if its done once a week, its similar to keeping the Sabbath). So our miner would help you Keep the Sabbath. You will wonder, how will we enforce it? I think we can have a REST URI built in, and have the sanctuaries run the RESTful web service, and ban miners who arent repenting coherently. Their miners would be shutdown. It could be a service we require of the sanctuaries.
I think these two features would make BiblePay consistent across all platforms, and require a level of participation to weed & feed out the wheat from the chaff in the community.
Thank you for the clear explanation of the changes.
One risk to the "repent" to mine is that you would encourage "false repentance" which in some circles is tantamount to encouraging additional sin. You also run the risk of alienating the people who are non-religious but have a spirit to help. If I'm an honest person but agnostic, but I enjoy the idea that a large portion of this coin benefits the less fortunate, a forced repentance puts one in a tough situation. Do you be honest and say, "I'm agnostic and there is good and evil but no metric for sin", do you go against your moral code and lie saying "today I ate shellfish" or do you drop the coin? Furthermore, depending on who is the arbiter of if the repentance is coherent, you risk the gatekeepers deciding what is and isn't a sin, which is a pretty complex thought seeing as how most people pretty much pick and choose what parts of the Bible are "right" (no adultery) and "outdated" (no shellfish).
In the end, I think the repentance concept is interesting but you would end up alienating a good portion of the user base or at a minimum not have the desired results. A better option might be for there to be some task to do. Any task is going to be "gamed" at rate that is directly proportional to the inconvenience of it and you have to consider the number of users that will be running from the command line. Having repentance as an option in the wallet is good, much like prayer requests. But I'm of the opinion that forcing any activity is going to be alienating and damaging to the coin.