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

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.

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

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

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

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.

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?

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?

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.

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

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.

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

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

Btw guys, to show everyone the pool is 100% honest, I added a command to the RPC to allow people to audit the pool:

if you type 'run subsidy blockheight', it will show the payee address and subsidy.  The pools address will be clearly seen and repeating block to block and will also be in the About page of the pool.

So, people can easily see the pool has every block its been paid in its block_distribution report.

Im going to run the pool free of fees to get us started.

I might add a 'tithe' % later when we get close to opensource it - something like a mixture of tithe% and poolfee% (thats for people who run pools in the future, to customize the fees).

You basically have to create the biblepay.conf in the root (where the blocks file is) and clone it into the \testnet3 folder.

Then start qt like this:

biblepay-qt -testnet

Then ensure you have a green background when you boot, and that it is mining against the pool (with getmininginfo).

Yes, and I apologize, I accidentally shut the GUI down for about 30 mins earlier without realizing, looks like everything is up now, now Im going to just let it run for a few hours and see how everyones hash distribution turns out in block_distribution.

sorry dev..bat what is file conf.  for testnet?  thanks for your support

{
  "blocks": 301,
  "currentblocksize": 0,
  "currentblocktx": 0,
  "difficulty": 0.0003173418615508064,
  "errors": "",
  "genproclimit": 1,
  "network_khashps": 153.8013017058758,
  "hashps": 0,
  "minerstarttime": "1-1-1970 00:00:00",
  "pooledtx": 0,
  "testnet": true,
  "chain": "test",
  "biblepay-generate": false,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "",
  "poolmining": false
}
this is right info or not?

You are mining against main chain

Start wallet in testnet mode

We currently have 299 blocks in testnet (not 2000)


Balance was updated to 0 when I found users mining against main chain, at that point I shut down MAIN and reset balances.

Try mining against testnet now.

wallet is sincro  is okk...but  {
  "blocks": 2144,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 0.001515689064373363,
  "errors": "",
  "genproclimit": 10,
  "network_khashps": 2812.859580438268,
  "hashps": 3812.064713273046,
  "minerstarttime": "08-07-2017 19:43:10",
  "pooledtx": 0,
  "testnet": false,
  "chain": "main",
  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "HEALTH_DOWN",
  "poolmining": false
}
   

file conf

poolport=80
pool=http://pool.biblepay.org
workerid=rana666
gen=1
genproclimit=10
addnode=node.biblepay.org


+ balance pool  now is 0  ...before was more 4800

It means you are on the main chain.

Check the block count.

Hi Guys-

When I noticed the prod users mining against the pool I accidentally shut down the pool both TestNet and Main with HEALTH_DOWN.

It took me 10 minutes to fix the problem, so for a while it was busted, but everything is fixed now.


The block distributions are looking 100% accurate now since a couple hours ago.