Topic: BiblePay - TestNet Thread - Pool Testing for Proof of Bible Hash Pool (PoBh) - page 12. (Read 13217 times)

~ 7 MHPS pool found only  2 blocks  today ?   

Yeah, you must be reading my mind.  Good finds/observations.
Well, this is sort of an eye opening experience actually.  The difficulty readjustment does not take into account independent adjustments for each algorithm. 
I agree, with the test harness metrics, someone with a lot of time on their hands could offload the X11 hash (as of when we released the wallet with the faster hashing speed and the outer X11 loop).
I mentioned two things in the next mandatory that would make the wallet smoother: preventing the block clumping, (thats a constant retarget), and lowering the stuck block threshhold.
I now want to add: tackle the diff readjustment per algo, and remove the difficulty of the x11, another words, we should put All of the onus on solving the block basing it off of the PoBh difficulty level only.  I believe we can accomplish this by lowering the difficulty of X11 down to miniscule amount, and testing this in testnet.
I would consider this an emergency, but we need to test thoroughly, and we dont want to tick off ccex.  We need to give them at least a 2 week notice.
Ill get to work on a new testnet version for us with these mandatories features to be ready by Friday for testing, then on the weekened we can announce an upgrade to them for about 14 days later.

In the mean time, I believe the pool problem will be fixed, it passed UAT and now I need to compile the windows wallet.

Findings thus far:

-After restarting the node of the miner (jaapgvk_audio) it's 'hashes per sec2' started to rise on the leaderboard, at one point even exceeding the 'hashes per sec'. Now it's hovering at about 50% of the actual hashrate.

-I can confirm that 'sjappie_miner' also showed '0 HPS' when it fell of the leaderboard. Does it fall off the leaderboard when the reward drops to zero? That would explain the disappearing and reappearing of a low hashrate miner (because the fluctuations in 'hashes per sec2' cause miners with a low hashrate te drop below the threshold of 1 reward).

-'RandomMiner' consistently has a 'hashes per sec2' that is on par with the actual hashrate of his miners. He also strikes me as a 'professional miner' since he has many rigs with high hashrates. Maybe he has tweaked his config/computer in a way that allows him to mine much more efficient than for example my own miners.

I don't believe the network hash rate from getmininginfo is based on values reported by miners, but rather calculated based on the average time that the network takes to find blocks at a given difficulty. I could be wrong, though.

Actually I already thought about this and I have a crazy theory, but what if someone somehow managed to use GPU for mining and their hash value would be close to zero because it would read from the CPU? Then we would have the answer to the net hash being a lot bigger than it shows (and the answer to who is stealing all the blocks ).

I'm  wondering how the shares are distributed atm of payout based on HPS .   
is it an average HPS for the period since last block or the running total for the user at the moment of payment ?

Yeah, that's what I meant. The pool was finding too few blocks relative to the network hash rate, meaning that the network hash rate must be wrong. Network hash rate approximations can be wrong, but everyone is mining against the same algorithm so the rate at which you're finding blocks over a statistically relevant period of time is the most objective reference.

A little off-topic, but about the time spent on X11 vs time spent on Biblehash - since X11 comes first and is independent of Biblehash, do you think it's possible someone could build a hybrid GPU miner? Using a GPU to find X11 solutions, and simultaneously feeding those into the CPU to run Biblehash on? Whether there'd any benefit to that would likely depend on where the CPU is spending the majority of its time, I suppose. Since it sounds like Biblehash is the bottleneck it's probably not a concern, but if it turns out that the opposite is true then it could be an issue.

Also, it looks like the X11 hash and the Biblehash hash are being compared against the same hashtarget value in the miner code. Do you know if the difficulty readjustment takes this into consideration? This is way outside of my field of knowledge, so maybe I'm thinking about this wrong, but imagine a scenario like this:

>1 out of 100 hashes are solutions at difficulty X
>0.01 probability of finding an X11 solution
>0.0001 probability of finding an X11 solution that also produces a Biblehash solution

>1 out of 200 hashes are solutions at difficulty 2X
>0.005 probability of finding an X11 solution
>0.000025 probability of finding an X11 solution that also produces a Biblehash solution

So, the difficulty adjustment system might have expected this to double the block time, but doubling the difficulty actually increased it by 4 times. Just for the record, I haven't looked at the code related to calculating difficulty at all, I'm just wondering. -edit- Block time probably isn't a good term to use there, I mean doubling the difficulty so the block time would remain consistent after readjusting for a doubled network hash rate.

Okay, I've restarted the node (jaapgvk_audio). Let's see where it goes from here.

Also, 'sjappie_miner' has reappeared on the leaderboard on it's own in the meantime. (Didn't restart it or anything.) I think - although I'm not certain - that the miner also showed '0 HPS' in my account tab when it dissapeared from the leaderboard.

I will restart in about ten minutes

Thanks, I hope in general people like the project and then interest will grow and we become a household name.
So I think to answer this question we can do a live test.
I have one miner bible_pay 'pc' showing right now at 10% in hashespersec2.  Rebooting the node (its been mining all night).

If the hashespersec2 increases to 90% of the HPS, then we know the answer will be not the pool and in the minerthread report to pool for stale share logic.

If you want to restart your slow node right now we can do a side by side test.

I really love the 'proof of bible', because of both the theoretical concept and the specific content. I can also envision why this would create the need for calculating the network_khashps in a different way. I hope you can find a way

I also had a miner lagging behind and eventually dropping off (sjappie_miner). It was only mining at around 20khashps, maybe that's why it was more likely to drop out? I think this was the second time it dropped of the leaderboard. The first time the miner reappeared on it's own as far as I know, but now it's been off the leaderboard for quite some time.

As far as I understand, this has to do with the 'Hashes Per Sec2', right? Can anyone please explain to me what this number means? Does it have to do with the ability of the miner to report it's 'proof of work' to the pool? A lot of the time, the 'Hashes Per Sec2' from my miners is around half of the 'Hashes Per Sec' (one miners is at around 20% right now in terms of 'Hashes Per Sec' vs 'Hashes Per Sec2'. Sadly, I don't have access to my miners right now, so I can't restart the nodes.

So, you think this problems has it's source in the pool or in the individual miners?

Im glad to hear youve potentially found the issue with the total network hash!

You're doing fantastic work, I look forward to the future of this project!

>>clicking  logout helped

So if anyone cant login to the pool, click logout a few times and then login and then logout-login-login etc.  I have logging in that area now.

Whats interesting about that is I had that problem this morning, so I bounced it and was able to get in.
However when You had that problem I was able to log in.

Ill put some logging in there and see if we can fix that.

So about the pool in general:
Im fairly happy overall about most of it and slightly dissapointed about a small part of it.
On the bright side, its not the server that is getting overloaded, looking at all the logs I think one server can handle the pool (although in the long term, it will be nice to have more than one pool), I can see that every time a miner is ready for more work (IE they send the readytomine packet), we receive and send 100% of the time, and have no issues.
There seems to be an issue left where the pool is not receiving every solution.

This is why ocasionally, you see a miner lagging behind further and further and finally diminishing to 0 and falling off leaderboard.

This can currently be solved by restarting the node (not doing a setgenerate X).  This is because the pool creates new share guids when you do that and then your hashps slowly rises back to its value.  This appears to only be happening to about 10% of the users.

So, today I will work on fixing that and implementing the metric to allow us to see the ratio of x11:biblehashes.  

On a side note, I have been working on adding the ability to read the bible from the wallet.  We already have the entire bible compiled in the wallet, so I know we need this feature inside the wallet for the GUI.  

(You can already read a verse from the RPC with 'run readverse booknumber chapternumber versenumber'.)

can't get in the pool c panel :  http://pool.biblepay.org/Login.aspx

login form doesn't work . looks like IIS needs a kick

I agree with all this, except that I think the pool is receiving the correct amount of blocks for the userbases network hash level, as I really feel that only 5% of our base came over.  Since we have not actually advertised it yet as ready for prod, I think 95% is still solo mining, but then I could be wrong about that.

If 5% really did come over, the wallet hash rate would be about 20* higher than the sum of the pool.  (You sum to 8.2 Mh/s).  That would put us at 165,144,280 or 165Mh/s total network (8257214*20).  The old getnetworkhashps (btw that command still works) bears 12,882 currently in prod - if we multiply * 10000, we arrive at 128,820,000 which would be closer to what I expect.  

Looking at the code for networkhashps, it just subtracts the old chainwork (from the beginning of the sample period) from the latest chainwork (from the end of the sample period) and does some averaging to arrive at how many hashes it should take to do that much chainwork.  What is probably happening is the PoBh algorithm is much harder to solve than the standard sha256 or x11 hash.  Apparently 1000* harder.  

I believe to solve this, we will need to allow more of the network to jump in the pool and get a feel for how this thing goes, and then release a fix for networkhashps.   If all goes well we will just multiply it * 10000, but in the mean time, let me look at the actual work done in the loop by the biblehash vs the x11 loop.  Its leading me to believe that a CPU must perform 1000 iterations of the loop to hash one bible hash as compared to one x11 hash.  That actually sounds relatively feasible.

EDIT:  I have an idea that might help shed light.  I can put a counter metric inside our PoBh mining loop that will shed light on how many x11 hashes it takes to hash one bible hash, and that should clarify this a great degree.

Haven't had any issues with the pool overnight. First block reward should be maturing soon and we'll see how withdrawals go.

The rate at which we're getting blocks seems a little low. Summing the 'hashes per sec' column on the leaderboard is currently giving 8,257,214 H/s.  That's nearly 63% of the network hash (going by 1.0.1.9's network_khashps value of 13,142,217 H/s). If you go based on HPS from the block distribution reward table, it's about 6,216,672 H/s, or ~47% of the network hash as of block 3225.

I kind of suspect that the reported network hash rate is significantly under-reporting.  I really doubt 47-63% the network's hash power has jumped into a test phase pool. That also seems a little more centralized than I'd expect from a CPU-mined coin, with 24 users running about 80 nodes contributing 1/2 to 2/3 of the network hash when even a low end machine should be putting out ~50 KH/s (0.4% of the reported network hashrate).

But the pool is not finding 38/100 blocks. Hence my questions - who are finding all the blocks, how are they doing it, and for how long has it been going on?