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

hi dev...i have HEALTH_DOWN in the getmininginfo, in field #2....what is my problem?  can you help me?  i must change my file.conf?  + my uncorfirmed  pool  balance is 0...before was more 4800

http://pool.biblepay.org/ is down since you mentioned version v1002 (error 403)

Even on the testnet, i got this with getmininginfo a few minutes ago



Edit: At the moment looks OK


1 connection only and on block 295 (testnet)

Everything looks good now- please provide details.

Also, we are in sync.

i have stop pool mining i wait for stable upgrade please...

I noticed we had 7 people poolmining against Prod (ie the main chain), and that reminded me to enable our HEALTH_DOWN feature.

It is now enabled in prod, so if you try to pool mine against prod you will see HEALTH_DOWN in the getmininginfo, in field #2.

this is useless.cant sync last 22 hours

Try:
addnode=node.biblepay.org
Restart

wallet in test not sync.

I just release v1002 of the pool (the little green box has the version in it when you log on).

These changes have been made:

- The pool is now smart enough to scan the last ten blocks once per minute and pick up any mined block credited to the pool, and distribute out its earnings (into block_distribution).  This should technically fix the bug where the pool misses mined blocks.  It rewards 0 for the tithe blocks, obviously.

- The Withdraw page now has an immature balance and a balance, to prevent people from withdrawing immature mined coins.  The maturity time is 24 hours.

I had to clear the block_distribution table so we can start over with a new baseline.

Miner2 is in a VPS and it floats around 580 hps with 4 threads, so the hashrate reporting is correct on both miners.

Running "biblepay-qt.exe -testnet" loads the main .conf file instead of the settings in the /testnet3 folder, as i have set different miner on each .conf file, but i guess this doesn't affect the main pool.

Possibly see if anything is in the log that is revealing?
Also verify the config is set both in biblepay.conf and in the \testnet3 dir:

pool=http://pool.biblepay.org
genproclimit=10
poolport=80
workerid=r15


SIDE NOTE:  poolport is not really required, client defaults 80.

Thanks, checked the timestamp and it was 09:47am, so it looks like the pool pulled in a bad height somehow, Im still trying to figure out how, but I think this will be fixed when the system is revamped to work the new way (lastblock solved+N to tip) during each round, etc.

Updated to the last wallet, added a worked on the website, and added that worker along with the other info to the config file in the testnet3 folder. But when I do a getmininginfo it says poolmining false.

Actually, I believe I did mine a block last night right after I synced. I had the .conf set up as described in the OP using happy_merchant as the worker id, but I didn't have an account set up with the pool.

Thank you sir for all the testing.
So your right, the mined blocks are not really mature yet in the pool, and it would actually go bankrupt if I left it this way (as pool would run out of money during withdrawals), so I need to add an immature balance and a mature balance for each user, to prevent that and track the maturity.

On a side note I went for the SQL credit mechanism so that if these pools become popular we will have a very efficient system, meaning that the pool receives the credit, and miners dont have to withdraw right away they can leave the balance in the pool for 2 weeks at a time and just let it accrue and then get it out in one transaction.

Alright Ill look into that.

Things appear to be working 'fairly' well except for a couple problems I see.

On the bright side, I see we have about 20 people who are testing, and the hashmeters appear to be working properly.
The leaderboard shows what appears to be the correct HPS per user.

On a side note, please check your HPS per miner in the leaderboard, and let us know if it is off so we can improve the pool.
I see flyingfish has a miner2 that is about 610 hps- you are a great candidate to help us test this out, is that what your getmininginfo hps shows flyingfish?

So the biggest problem I see is the block distribution.  On a side note I see happy solved a block over 125 blocks prior (block 134 if you look at block distribution report), and that is strange, I dont know if we forked when everyone jumped on (I havent been around for a couple hours) or if its a bug in the pool.  So that is one thing I need to check.
The other issue is: The pool is missing block payouts.  I believe it needs some code added to ensure it has the ability to go back from the best block to the last solved block of the pool, and fill in any missing block distributions and mark them as unpaid, just in case we are credited in the pool for a solved block and we have no idea why, and  it does have all the info as far as hashespersec and participants in order to do that.  So that is the biggie.  Ill work on that next.  

So in summary its working at about a 70% accuracy level.  Your accounts are being credited (IE shortpayed) so now you can test a withdrawal if you want.

 

Seems to be an issue on the block distribution history page on the pool site. Block 269 was added to the top of the table and listed as block 134:


Aside from that, the hash rate appears to be reported correctly and the reward was properly credited to my account. I was also able to withdraw into my wallet.

I'm a little confused, though. When you solo mine a block, I believe it normally takes 100 blocks to mature and transfer into your available wallet balance. With the pool, I was able to withdraw my share of the reward directly into my available balance (with a single block delay for the pending transaction).

I have the new wallet working  fine on mainnet(no mining), but Crashes when I attempt testnet... will update if i can work out why.

One thing I forgot to mention:
Once you get everything set up, on the web site side, you have to click 'Switch to TestNet' every time you log in otherwise the pages, the reports, the hashes, everything will be against the wrong tables.  TestNet hashes against pool testnet, Main hashes against pool Main, but the GUI is all consolidated and relies on the user choosing the network ID every time they log in.

To test this:

Click 'switch to testnet', then click Block distribution and you should see the testnet distribution.

Good morning all!

Alright the pool is deployed here, so you can create web accounts and miners now:

http://pool.biblepay.org

Looks like testnet is running properly and I have a couple testers connected to my node.

So now go ahead and follow the instruction in the OP and lets see where our snags are.

I mined overnight against the testnet pool, and it worked for the most part but I did find a bug in 2 of the block payouts (out of the 12 I mined) these two block payouts were zero, and for some reason, when the pool asked the testnet external node for the block subsidy it returned zero - so if you look in the block distribution, you will see what Im talking about- so I will work on that today (while we test more blocks)-  I have a feeling its a race condition where the miner solved the block but the external node didnt even know about it yet, or something like that.

As far as open sourcing the pool: Yes, I am willing to do that, because it would also be nice to have more than one biblepay pool for users to hit, so all the users dont pound my server alone.  I think after about 100 concurrent users, my servers going to be pretty busy.  The main thing we have to address before its open sourced is to get the payout algorithm working reliably so we can tell if anyone makes a fraudulent compile and therefore the pool will catch that and still pay a rock solid hash reward back and the other thing that needs done, is to ensure the pool has sql injection protection on it, so no hacker can come in and steal the pools BBP balances - when I feel those are solid then we can post the code.