BiblePay - TestNet Thread - Pool Testing for Proof of Bible Hash Pool (PoBh)

[jaapgvk]

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'.)

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?

[1715067522]

1715067522

[1715067522]

1715067522

[1715067522]

1715067522

[bible_pay]

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'.)

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?

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.

[jaapgvk]

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

I will restart in about ten minutes

[jaapgvk]

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

I will restart in about ten minutes

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.

[happy_merchant]

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.

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.

[tiras]

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 ?

[inblue]

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.

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 ).

[happy_merchant]

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 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.

[jaapgvk]

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

I will restart in about ten minutes

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.

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.

[bible_pay]

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.

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.

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.

[tiras]

~ 7 MHPS pool found only  2 blocks  today ?   

[happy_merchant]

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.

Sounds like a sensible solution. It'd essentially be like adding a 12th algorithm to X11 and would simplify difficulty retargeting and network hash calculations. That'd also eliminate any risk of a hybrid GPU miner, since the overhead of reading back from the GPU every single iteration would far outweigh just performing a low difficulty X11 on the CPU.

I was looking through the DakGravityWave difficulty readjustment algo, adjusting that to try to balance two difficulties for two hashes would be messy. It'd be highly dependent on metrics on both hashing algos and end up being really fragile if anything changed in either of them. Always best to go simple when possible.

[bible_pay]

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.

Sounds like a sensible solution. It'd essentially be like adding a 12th algorithm to X11 and would simplify difficulty retargeting and network hash calculations. That'd also eliminate any risk of a hybrid GPU miner, since the overhead of reading back from the GPU every single iteration would far outweigh just performing a low difficulty X11 on the CPU.

I was looking through the DakGravityWave difficulty readjustment algo, adjusting that to try to balance two difficulties for two hashes would be messy. It'd be highly dependent on metrics on both hashing algos and end up being really fragile if anything changed in either of them. Always best to go simple when possible.

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.

[bible_pay]

Ok guys this is just a notice for a testnet release of the next upcoming version 1021:

1.0.2.1 - Non-Mandatory Release

- For upcoming mandatories rule @1350(testnet)||@7000(Prod), Testnet features: test anti-block-clump retarget rule, slow_block_threshhold = 30 mins rule,
 and lowering x11 difficulty by 300%, and ratio of x11:biblehashes in getmininginfo
- In wallet Bible Reader (Help | Read Bible).  NOTE: You currently must choose the Book after the page loads.
- Fixes for in-wallet pool-miner (fixes diminishing KHS)
- adjustment to getnetworkhasps

Note that Windows will take another 6 hours to compile and I will be gone, so that wont be out til tomorrow morning.

In the mean time heres what I need help on:  I cant mine the next block in testnet on my linux rig as we left the diff too high.  So if anyone wants to get the latest from github on linux and jump on testnet it would be appreciated.

What I am trying to test with you guys next is bullet item #1.  At block 1350, we start decreasing the diff of the X11 hash by 300%.  I have a couple new features in there that will show how much % of the onus is on the biblehash as of the new version, Ill explain where that is once we mine a few new blocks.

Tomorrow if this version mines, we can release the windows version and that version allows the pool to work properly (without the diminishing HPS).

[togoshigekata]

I went missing on the leaderboard and HPS showed 0, and now its back, weird >.>

[jaapgvk]

Ok guys this is just a notice for a testnet release of the next upcoming version 1021:

1.0.2.1 - Non-Mandatory Release

- For upcoming mandatories rule @1350(testnet)||@7000(Prod), Testnet features: test anti-block-clump retarget rule, slow_block_threshhold = 30 mins rule,
 and lowering x11 difficulty by 300%, and ratio of x11:biblehashes in getmininginfo
- In wallet Bible Reader (Help | Read Bible).  NOTE: You currently must choose the Book after the page loads.
- Fixes for in-wallet pool-miner (fixes diminishing KHS)
- adjustment to getnetworkhasps

Note that Windows will take another 6 hours to compile and I will be gone, so that wont be out til tomorrow morning.

In the mean time heres what I need help on:  I cant mine the next block in testnet on my linux rig as we left the diff too high.  So if anyone wants to get the latest from github on linux and jump on testnet it would be appreciated.

What I am trying to test with you guys next is bullet item #1.  At block 1350, we start decreasing the diff of the X11 hash by 300%.  I have a couple new features in there that will show how much % of the onus is on the biblehash as of the new version, Ill explain where that is once we mine a few new blocks.

Tomorrow if this version mines, we can release the windows version and that version allows the pool to work properly (without the diminishing HPS).

Very nice! I don't have a Linux-rig, so I can't help you with mining the next block, but I will update to 1.0.2.1 as soon as the Windows version comes out and start a miner on the testnet again

[jaapgvk]

hmm Im missing on the leaderboard, on the account page, my HPS shows 0 as well

Whereas just a bit ago, I was on the leaderboard and the  account page showed me at 24k hps

Weird just checked again and now Im back on the leaderboard and my HPS is back on the account page >.>

Yeah, I experience the same thing. I think it has to do with the 'diminishing khashps bug'. My guess is that if it dipps below the '1 reward threshold' you get removed from the leaderboard (and also, the miner won't show up in your account tab). As soon as it's above the threshold, it will show up on the leaderboard again.

But thankfully, this will probably be fixed in 1.0.2.1.

[happy_merchant]

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.

[bible_pay]

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.

[happy_merchant]

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.

Hmm, I think something's wrong in the latest commit. When you enable mining, biblepay_generate is set to true but hashps is 0 and there's no CPU load. Issue is present for both pool and solo mining.