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

[jc12345]

I wonder if the botnets will join the pool or if they will keep on solo mining.

[1713946525]

1713946525

[1713946525]

1713946525

[bible_pay]

I wonder if the botnets will join the pool or if they will keep on solo mining.

Mini Update:

50% of the problem is solved, but there is a remaining issue with the web server dropping packets.

Working...

[bible_pay]

Its working a little better now, but I believe something else still needs fixed, I have to run an errand.
Lets see if we solve a block against prod.

Be back in an hour.

[jaapgvk]

My findings thusfar.

On testnet:
1. Did a withdrawal. It was instant and without problems.
2. The leaderboard doesn't seem to function.
3. Tiras recieved the entire subsidy on blocks 1241-1241 (thus far) although I'm still mining (and I guess the rest is also still mining).

On mainnet:
1. My 'Hashes Per Sec2' was pretty low for a while on the miner called 'jaapgvk_kamer'. I don't know why. It was hashing away just like my other miner on de pool, and that miner had a 'Hashes Per Sec2' that was about the same as the 'Hases per Sec'. But I don't know enough about poolmining to know if this is normal

Oh, and the first block was mined it seems!

[JesusCryptos]

I didn't understand at all what the project is about, but the very concept of Proof of Bible is brilliant. Trust me, I'm JesusCryptos!

[bible_pay]

My findings thusfar.

On testnet:
1. Did a withdrawal. It was instant and without problems.
2. The leaderboard doesn't seem to function.
3. Tiras recieved the entire subsidy on blocks 1241-1241 (thus far) although I'm still mining (and I guess the rest is also still mining).

On mainnet:
1. My 'Hashes Per Sec2' was pretty low for a while on the miner called 'jaapgvk_kamer'. I don't know why. It was hashing away just like my other miner on de pool, and that miner had a 'Hashes Per Sec2' that was about the same as the 'Hases per Sec'. But I don't know enough about poolmining to know if this is normal

Oh, and the first block was mined it seems!

Thats great we found a block, although Im kind of surprised we didnt find 2 by now.

Anyway on testnet, I think what happened is when I was disconnecting the pool over and over I disconnected you long enough to fall out for more than 10 minutes, and you didnt make it back in by the time JaapG got the 2 blocks as a lone miner.  The leaderboard is now empty because everyone bolted.  I think testnet should be working again, if anyone were to hash against it.

On mainnet, the low hash issue  seems to be a problem if the miner has a lost old pool thread until you reboot the client.  Its probably the workguid being caught in one of the threads for extended period.  If you are running 1020, just reboot the client and continue against the pool and see if the hashes increase to the boxes amount.

Over the next few days Ill see what I can do to make it auto recover threads that do that (on the qt client side).

[tiras]

My findings thusfar.

On testnet:
1. Did a withdrawal. It was instant and without problems.
2. The leaderboard doesn't seem to function.
3. Tiras recieved the entire subsidy on blocks 1241-1241 (thus far) although I'm still mining (and I guess the rest is also still mining).

On mainnet:
1. My 'Hashes Per Sec2' was pretty low for a while on the miner called 'jaapgvk_kamer'. I don't know why. It was hashing away just like my other miner on de pool, and that miner had a 'Hashes Per Sec2' that was about the same as the 'Hases per Sec'. But I don't know enough about poolmining to know if this is normal

Oh, and the first block was mined it seems!

Thats great we found a block, although Im kind of surprised we didnt find 2 by now.

Anyway on testnet, I think what happened is when I was disconnecting the pool over and over I disconnected you long enough to fall out for more than 10 minutes, and you didnt make it back in by the time JaapG got the 2 blocks as a lone miner.  The leaderboard is now empty because everyone bolted.  I think testnet should be working again, if anyone were to hash against it.

On mainnet, the low hash issue  seems to be a problem if the miner has a lost old pool thread until you reboot the client.  Its probably the workguid being caught in one of the threads for extended period.  If you are running 1020, just reboot the client and continue against the pool and see if the hashes increase to the boxes amount.

Over the next few days Ill see what I can do to make it auto recover threads that do that (on the qt client side).

low hash client issue seems to be resolved.   if we all are mining live against the pool ATM it seems too long for another block to find .  too bad you can't see real time output as in GPU miners.

[bible_pay]

My findings thusfar.

On testnet:
1. Did a withdrawal. It was instant and without problems.
2. The leaderboard doesn't seem to function.
3. Tiras recieved the entire subsidy on blocks 1241-1241 (thus far) although I'm still mining (and I guess the rest is also still mining).

On mainnet:
1. My 'Hashes Per Sec2' was pretty low for a while on the miner called 'jaapgvk_kamer'. I don't know why. It was hashing away just like my other miner on de pool, and that miner had a 'Hashes Per Sec2' that was about the same as the 'Hases per Sec'. But I don't know enough about poolmining to know if this is normal

Oh, and the first block was mined it seems!

Thats great we found a block, although Im kind of surprised we didnt find 2 by now.

Anyway on testnet, I think what happened is when I was disconnecting the pool over and over I disconnected you long enough to fall out for more than 10 minutes, and you didnt make it back in by the time JaapG got the 2 blocks as a lone miner.  The leaderboard is now empty because everyone bolted.  I think testnet should be working again, if anyone were to hash against it.

On mainnet, the low hash issue  seems to be a problem if the miner has a lost old pool thread until you reboot the client.  Its probably the workguid being caught in one of the threads for extended period.  If you are running 1020, just reboot the client and continue against the pool and see if the hashes increase to the boxes amount.

Over the next few days Ill see what I can do to make it auto recover threads that do that (on the qt client side).

low hash client issue seems to be resolved.   if we all are mining live against the pool ATM it seems too long for another block to find .  too bad you can't see real time output as in GPU miners.

Good deal.


Lets try letting it run overnight and see how many we get and we can probably do the math on it (as the hashpersec2 will be in the block dist history) - maybe we will get a chunk of 3 or 4 in an hour early in the morning etc.

[bible_pay]

We can probably ask RandomMiner how many blocks per day he normally averages since he is bringing 1.18 MHS to the pool, it will be an interesting comparison.

[jc12345]

Is there a possibility that a botnet could be gaming the system and e.g. mine in the future so that it finds all the blocks? Someone is finding all the blocks it would just be interesting to know who it is and how they are doing it.

[FlyingFish]

Block 3174 found by the pool.

Once in a while getmininginfo returns no info on the pool

 "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "",

Instead of the normal

"poolinfo1": "B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; ",
  "poolinfo2": "0e4b2c7c-6273-4d48-8165-dd912294ea9d; ",
  "poolinfo3": "",

From the leader board list the pool has around 5MH/s and the inspector reports a network hash of 13MH/s
If i get these numbers right, we can expect to get ~38blocks  in 100. Correct?

Number of miner threads aren't being reported correctly. I have 7 and 2 on my miner.

Where is the post about 'Hashes Per Sec2'?

PS: using v1.0.2.0

[jc12345]

Block 3174 found by the pool.

Once in a while getmininginfo returns no info on the pool

 "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "",

Instead of the normal

"poolinfo1": "B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; ",
  "poolinfo2": "0e4b2c7c-6273-4d48-8165-dd912294ea9d; ",
  "poolinfo3": "",

From the leader board list the pool has around 5MH/s and the inspector reports a network hash of 13MH/s
If i get these numbers right, we can expect to get ~38blocks  in 100. Correct?

Number of miner threads aren't being reported correctly. I have 7 and 2 on my miner.

Where is the post about 'Hashes Per Sec2'?

PS: using v1.0.2.0

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?

[happy_merchant]

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

[bible_pay]

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

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.

[tiras]

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

[bible_pay]

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

[bible_pay]

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

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.

[bible_pay]

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

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

[tiras]

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

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

>>clicking  logout helped

[togoshigekata]

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.

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!