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

[gildinglite]

Do we get a random bible verse embedded in every coin?

What is the purpose of having the bible text in the wallet otherwise?

[bible_pay]

Do we get a random bible verse embedded in every coin?

What is the purpose of having the bible text in the wallet otherwise?

There are multiple purposes: the entire KJV bible is compiled in the coin, so using that in our PoBh algorithm, it makes it more challenging to port the miner to an asic.

The text itself gives us a chance to 'potentially' spread the gospel to more IT people (as a lot of people are poring over the source code).

Finally, having the verses available allows us to add features in the future that rely on verses (like in wallet prayer rooms) and verse of the day, etc.

[Slkp]

Now where should we mine?in test net or main?

[bible_pay]

Now where should we mine?in test net or main?

If you want to mine against prod, you can leave the settings the way they are and reboot into prod mode-and since the Prod pool sends HEALTH_DOWN, mining in prod reverts to solo mining automatically.

As far as going live, Id like to test this pool out for a few days, and receive some feedback (I have not received any feedback yet, anywhere), to ensure its meeting the needs of everyone.

[happy_merchant]

Left a laptop pool mining on the testnet all day. Hasn't seemed to be any issues on my end, no disconnections or anything. The hashrate for my worker appears to be reported accurately on the pool site. The reward shares seem to be calculated and distributed properly.

No issues doing withdrawals, aside from what appears to be a minor glitch with the withdrawal form on the pool site where it adds the immature balance to available balance field after making a withdrawal (so if you have 100 available bbp, 500 immature bbp, withdraw 1 bbp, it'd show 599 bbp in the available balance field). That's purely an issue with the form, though, it's not actually adding to the immature balance to the available balance and you can't actually withdraw more than you have available.

It seems like the pool uses unique worker ids to link miners to pool accounts. I messed around with that a little and wasn't able to create a duplicate miner name that someone else is already using or anything potentially exploit-y that way.

How does the pool ensure that all workers are actually doing the work they're reporting, by the way? Each worker's portion of the reward seems to be exactly proportional to the % of the total pool hashrate they're contributing. If this is just being reported by the client, there will definitely be people attempting to falsify their hashrate. Is there some kind of share system operating behind the scenes so the pool can verify everyone's doing the work they're claiming?

[vikingchild]

Hey! How is the mining doing? I mean if you have an Rx 480 or GTX1080/1070, what number of coins can you expect to mine on the pool per day or hour or whatever measure you prefer?

[happy_merchant]

Tested the pool miner using multiple workers, didn't seem to be any issue and each worker's contributions were recorded and credited to my account as expected.

Also tried multiple mining rigs using the same worker id. The hashrate of all rigs using the same worker id appeared to be summed in the block distribution table under the HPS heading and the share of the reward seemed to be correct. The hashrate on the leader board for the worker id gets a little weird when doing this, kind of like it's trying to take the average of the hashrates of the rigs or something.

[Charloz24]

Hey! How is the mining doing? I mean if you have an Rx 480 or GTX1080/1070, what number of coins can you expect to mine on the pool per day or hour or whatever measure you prefer?

It's CPU only, you can't mine with a GPU. The DEV created a new algo to be ASIC/GPU resistant.

[bible_pay]

Left a laptop pool mining on the testnet all day. Hasn't seemed to be any issues on my end, no disconnections or anything. The hashrate for my worker appears to be reported accurately on the pool site. The reward shares seem to be calculated and distributed properly.

No issues doing withdrawals, aside from what appears to be a minor glitch with the withdrawal form on the pool site where it adds the immature balance to available balance field after making a withdrawal (so if you have 100 available bbp, 500 immature bbp, withdraw 1 bbp, it'd show 599 bbp in the available balance field). That's purely an issue with the form, though, it's not actually adding to the immature balance to the available balance and you can't actually withdraw more than you have available.

It seems like the pool uses unique worker ids to link miners to pool accounts. I messed around with that a little and wasn't able to create a duplicate miner name that someone else is already using or anything potentially exploit-y that way.

How does the pool ensure that all workers are actually doing the work they're reporting, by the way? Each worker's portion of the reward seems to be exactly proportional to the % of the total pool hashrate they're contributing. If this is just being reported by the client, there will definitely be people attempting to falsify their hashrate. Is there some kind of share system operating behind the scenes so the pool can verify everyone's doing the work they're claiming?

Thanks a lot for the in-depth high quality testing, this helps immensely.

I see that you fired up a heavy duty miner in the middle of the night (where the reward was > 25000 hps) while you tested multiple workers per block and then multiple rigs pointed to one workerid.  I believe that part is working correctly, based on the data and HPS readings and the reward distributions - so Im happy there.

10-4 on the withdrawal bug, I created a (punchlist) item to update the balance properly.

Good that it seems that the pool has no security issue, related to mining against the wrong accounts.  Imo, if a person somehow discovers how to mine against anothers workerid, they would only be hurting themself, so thats why I dont enforce login credentials on the mining side.  The web site of course requires authentication to add new workers, but the client may mine against a workerid without authentication.  It does send 9 proprietary HTTP headers to the pool in order to receive the minerguid, but does not authenticate with any password.  The pool enforces unique worker IDs globally with a constraint. (Another words, User B cant create a miner named MINER if MINER is in use).

On the per share rewards, if you look closely at the block_distribution report, you will see the reward per miner is not exactly the same as the HPS reading that is reported in the leaderboard.  The number in parentheses is the number of shares solved by the miner during the round for that block * a synthetic number to arrive at a synthetic HPS reading.  The synthetic reading is in parentheses and is actually used to calculate that rows subsidy amount.  I am considering the fraudulent client issue, reporting the wrong work done per thread and hash count and resulting HPS, but yes, currently the HPS seems accurate because it is honoring what the client gives and using that for the leaderboard, but not for the payments.  I was originally planning on adding a type of police subsystem to the pool, to detect cheaters as I think it will be apparent on the server side by doing some math formulas based on either cheating time sequences, or cheating work done nonce counts or both, but actually today when I woke up I was thinking of adding another type of shares-submitted and shares-solved per round to the work table, to see how accurate that is per block instead, and possibly using that for the leaderboard, so thats sort of up in the air

[adorid]

Great job,
From my tests everything looks good...

[happy_merchant]

Ah, I wouldn't really call it in-depth testing, kind of just probing around at the low hanging fruit. If you have anything specifically that needs to be tested, let me know and I'll do what I can. I might try making some edits to the miner later to see if I can break anything with the pool by falsely reporting data or sending garbage or other obvious attacks.

As for the heavy duty miner, it was actually a VM that would normally only get around 8,000 H/s. I pulled 1.0.1.9 from github and the hashps skyrocketed. I figured it was a bug and was just incorrectly reporting the hashrate, which is why I asked about the pool verifying work. I looked through the source code since then and saw that some optimizations were made in the miner though, so maybe the performance actually did improve that much?

--edit--
Saw the post in the other thread, looks like it is a real performance boost.

[happy_merchant]

I disconnected from the pool and solo mined blocks 411 and 412 to see how the pool would respond to an outsider mining a block it was working on. The blocks were definitely solo mined and the block rewards were added to my wallet's immature balance. The block distribution history gives the impression that the pool still paid out to pool miners for those blocks:

Code:

ID					User Name	Height	Block Subsidy	Subsidy		Paid Date		HPS	PaymentPerHash	Updated			Stats
13a88588-0b07-42da-a8a7-256595d1438c	flyingfish	411	20000.0000	20000.0000	8/8/2017 10:27:59 AM	733.49	27.266777209204	8/8/2017 10:27:59 AM	testnet2: 551 (733)
de9a39f5-fb2a-4605-95ae-4aa1bbcf3788	flyingfish	412	20000.0000	20000.0000	8/8/2017 10:27:59 AM	733.49	27.266777209204	8/8/2017 10:27:59 AM	testnet2: 551 (733)

I didn't have a miner connected to the pool at the time so I can't verify whether or not pool miners were actually mistakenly credited for those blocks from my end.

[bible_pay]

I disconnected from the pool and solo mined blocks 411 and 412 to see how the pool would respond to an outsider mining a block it was working on. The blocks were definitely solo mined and the block rewards were added to my wallet's immature balance. The block distribution history gives the impression that the pool still paid out to pool miners for those blocks:

Code:

ID					User Name	Height	Block Subsidy	Subsidy		Paid Date		HPS	PaymentPerHash	Updated			Stats
13a88588-0b07-42da-a8a7-256595d1438c	flyingfish	411	20000.0000	20000.0000	8/8/2017 10:27:59 AM	733.49	27.266777209204	8/8/2017 10:27:59 AM	testnet2: 551 (733)
de9a39f5-fb2a-4605-95ae-4aa1bbcf3788	flyingfish	412	20000.0000	20000.0000	8/8/2017 10:27:59 AM	733.49	27.266777209204	8/8/2017 10:27:59 AM	testnet2: 551 (733)

I didn't have a miner connected to the pool at the time so I can't verify whether or not pool miners were actually mistakenly credited for those blocks from my end.

Im glad we are still testing as we need to work out the finer kinks.

So good news is some things behind the scenes partially worked but you did find a bug.
So on block 411 (when you pulled out of the pool) you didnt actually get that block, the pool still got it (if you do a 'run subsidy 411') you see the pools testnet address.  So that explains how flyingfish got the whole block 411, so that park worked correctly.
But by the time 412 hit, here is the pool bug hitting:  It did successfully double check 412, and find it was not paid for it, and avoided putting it in the blocks table, but for some reason, it went ahead and distributed the block and paid it, so I can see a condition where it realized it should not pay it but executed the remaining part of the service; Ill look into that now, but anyway this is very helpful.  Looks like we need to keep testing for a while longer and insure this is killed.

Thanks.

[bible_pay]

I disconnected from the pool and solo mined blocks 411 and 412 to see how the pool would respond to an outsider mining a block it was working on. The blocks were definitely solo mined and the block rewards were added to my wallet's immature balance. The block distribution history gives the impression that the pool still paid out to pool miners for those blocks:

Code:

ID					User Name	Height	Block Subsidy	Subsidy		Paid Date		HPS	PaymentPerHash	Updated			Stats
13a88588-0b07-42da-a8a7-256595d1438c	flyingfish	411	20000.0000	20000.0000	8/8/2017 10:27:59 AM	733.49	27.266777209204	8/8/2017 10:27:59 AM	testnet2: 551 (733)
de9a39f5-fb2a-4605-95ae-4aa1bbcf3788	flyingfish	412	20000.0000	20000.0000	8/8/2017 10:27:59 AM	733.49	27.266777209204	8/8/2017 10:27:59 AM	testnet2: 551 (733)

I didn't have a miner connected to the pool at the time so I can't verify whether or not pool miners were actually mistakenly credited for those blocks from my end.

Im glad we are still testing as we need to work out the finer kinks.

So good news is some things behind the scenes partially worked but you did find a bug.
So on block 411 (when you pulled out of the pool) you didnt actually get that block, the pool still got it (if you do a 'run subsidy 411') you see the pools testnet address.  So that explains how flyingfish got the whole block 411, so that park worked correctly.
But by the time 412 hit, here is the pool bug hitting:  It did successfully double check 412, and find it was not paid for it, and avoided putting it in the blocks table, but for some reason, it went ahead and distributed the block and paid it, so I can see a condition where it realized it should not pay it but executed the remaining part of the service; Ill look into that now, but anyway this is very helpful.  Looks like we need to keep testing for a while longer and insure this is killed.

Thanks.

Ok,

I fixed the two outstanding pool issues:  Balance is updated correctly now on the withdrawal form, and I found the condition where we pay when we should not pay, and corrected the logic.  Im going to mine against the testnet pool again and see if we can make this solid now.  We still need a few testers in testnet for a couple days, please join us, having only two of us is not very effective to exploit bugs.

Thanks.

[Slkp]

no info in Leaderboard.Still mine in testnet

[smoosh]

running a test with a laptop since it looks like im going to need pool mining before i ever get a coin. Spun up an 8 core azure machine with free credits and still nothing so far.

Anyway only thing i noticed so far is in your portal you are not checking for logged in status. I left and came back and clicked on a link and got a hard error instead of sending me back to the log in screen.

[bible_pay]

running a test with a laptop since it looks like im going to need pool mining before i ever get a coin. Spun up an 8 core azure machine with free credits and still nothing so far.

Anyway only thing i noticed so far is in your portal you are not checking for logged in status. I left and came back and clicked on a link and got a hard error instead of sending me back to the log in screen.

We check for logged in status- please paste the error so we can debug.

[smoosh]

running a test with a laptop since it looks like im going to need pool mining before i ever get a coin. Spun up an 8 core azure machine with free credits and still nothing so far.

Anyway only thing i noticed so far is in your portal you are not checking for logged in status. I left and came back and clicked on a link and got a hard error instead of sending me back to the log in screen.

We check for logged in status- please paste the error so we can debug.

http://pool.biblepay.org/Account.aspx
Invalid column name 'threads'.
Invalid column name 'BoxHPS'.

[jc12345]

Some feedback:

1. When you click on switch to testnet it toggles to switch to mainnet. When you click on another like like home, the link switch to mainnet defaults back to switch to testnet which is not correct.
2. There is no page to see stats on the blocks found, who found them, when found, the block's status etc.
3. No anonymous mining option.
4. Pool hash indicator is very close to client side hash

[bible_pay]

running a test with a laptop since it looks like im going to need pool mining before i ever get a coin. Spun up an 8 core azure machine with free credits and still nothing so far.

Anyway only thing i noticed so far is in your portal you are not checking for logged in status. I left and came back and clicked on a link and got a hard error instead of sending me back to the log in screen.

We check for logged in status- please paste the error so we can debug.

http://pool.biblepay.org/Account.aspx
Invalid column name 'threads'.
Invalid column name 'BoxHPS'.

Thanks a lot dude!  So of course when we go live, we can turn off verbose debug info.  But this helps, as this is basically a spoof URL security item, in a way.  On a side note, this happens when the users session auto-expires and then they try to spoof a URL.  Ill jump on this.