Good morning, the windows version is now available at www.biblepay.org as the normal client download.
Please upgrade to 1.0.2.0 and then we can continue pool testing.
The remaining items to test:
- Ensure hashps is relatively fair and consistent per miner
- Ensure payments are correct
- Ensure new windows version no longer crashes when pool mining in testnet (this only happened to me, so I did add mutex code to prevent writing to the shared area)
Topic: BiblePay - TestNet Thread - Pool Testing for Proof of Bible Hash Pool (PoBh) - page 15. (Read 13217 times)
August 13, 2017, 07:07:37 AM
August 12, 2017, 10:57:56 PM
All- I did a bad deploy - please hang on, Im working on fixing it now.
Ok, heres the deal, the web site side of the pool is now updated and working, but the biblepay client will now need updated to hash against the pool.
(The issue is, the prior versions had a couple settings that popped up at block 1000 in testnet, and requires a mandatory for testnet only to alleviate those problems).
This requires an overnight build for windows.
If anyone wants to hash in testnet against the pool tonight in Linux you can git v1.0.2.0 and start again.
I will update everyone in the morning with the windows version.
August 12, 2017, 05:41:12 PM
All- I did a bad deploy - please hang on, Im working on fixing it now.
August 12, 2017, 05:04:26 PM
Wow, looks like a lot of hard work is going into this! Definitely looking forward to having the pool fully up and running!
August 12, 2017, 04:39:16 PM
Yea, Ive been coding/releasing/tweaking behind the scenes now for 4 hours and finally released the share based decay function. I dont think its been behaving properly.
Starting now going forward, if you hop in the pool, it takes a good 2 minutes for it to 'warm up' and build up some credits and you will see on the leaderboard the hashpersec2 will increase. If you decide to pull out and switch miners, you should see a relatively rapid decay from the old workers shares decay down to 0 over 5 minutes or so.
Lets see if this behaves more sane now
.
I just compiled a new windows version with some bug fixes for the pool; which OS are you running happy?
Starting now going forward, if you hop in the pool, it takes a good 2 minutes for it to 'warm up' and build up some credits and you will see on the leaderboard the hashpersec2 will increase. If you decide to pull out and switch miners, you should see a relatively rapid decay from the old workers shares decay down to 0 over 5 minutes or so.
Lets see if this behaves more sane now
.I just compiled a new windows version with some bug fixes for the pool; which OS are you running happy?
Running Windows on the machine I'm using for the testpool.
August 12, 2017, 04:32:51 PM
I forgot to mention, I just updated the pay function to use the new decaying HPS (thats hashespersec2 on the leaderboard) starting on block #1005. So starting now you can pool hop and see if we decay and pay properly.
August 12, 2017, 04:21:37 PM
The rounds are currently 10 minutes, so it takes 10 minutes to fall out of the round. I think thats OK, as the new shares based system decay function will pay less and less hash per sec as you fall out of the round.
These blocks were solved so fast it literally had the same values it looks like.
These blocks were solved so fast it literally had the same values it looks like.
I see. I'll keep it running for a while and see how it works out.
And as I was typing that it looks like block 983 just got listed. happy_worker was removed and happy_merchant's HPS went back to normal.
Also looks like something kind of weird going on with the other miners between blocks 979 and 983. lastleg's HPS plummeted while Anonymous' and testbible's HPS skyrocketed. The timing is just a little strange to happen all at once and during the blocks where happy_merchant00 and happy_worker were double listed.
Actually, 3 of those were also those instant mine blocks, so it might just be something because of that. I'd imagine the share statistics get a little weird when a block is instant mined.
Yea, Ive been coding/releasing/tweaking behind the scenes now for 4 hours and finally released the share based decay function. I dont think its been behaving properly.
Starting now going forward, if you hop in the pool, it takes a good 2 minutes for it to 'warm up' and build up some credits and you will see on the leaderboard the hashpersec2 will increase. If you decide to pull out and switch miners, you should see a relatively rapid decay from the old workers shares decay down to 0 over 5 minutes or so.
Lets see if this behaves more sane now
.I just compiled a new windows version with some bug fixes for the pool; which OS are you running happy?
August 12, 2017, 01:41:22 PM
The rounds are currently 10 minutes, so it takes 10 minutes to fall out of the round. I think thats OK, as the new shares based system decay function will pay less and less hash per sec as you fall out of the round.
These blocks were solved so fast it literally had the same values it looks like.
These blocks were solved so fast it literally had the same values it looks like.
I see. I'll keep it running for a while and see how it works out.
And as I was typing that it looks like block 983 just got listed. happy_worker was removed and happy_merchant's HPS went back to normal.
Also looks like something kind of weird going on with the other miners between blocks 979 and 983. lastleg's HPS plummeted while Anonymous' and testbible's HPS skyrocketed. The timing is just a little strange to happen all at once and during the blocks where happy_merchant00 and happy_worker were double listed.
Actually, 3 of those were also those instant mine blocks, so it might just be something because of that. I'd imagine the share statistics get a little weird when a block is instant mined.
August 12, 2017, 01:20:52 PM
Oh ok I see 965 now. Just so you know, I havent switched to paying based on the shares yet, it still pays the same way, but I have the figures on the back end.
Anyway I would really like to debug that happy_merchant high hash payment, do you think you can go back to mining with the broken miner? Maybe it will become clear how that is happening? In the mean time Ill try to reproduce.
My goal is to start payments based on "hashespersec2" that is in the leaderboard, that number is based on shares solved in the current round * difficulty of the share.
Anyway I would really like to debug that happy_merchant high hash payment, do you think you can go back to mining with the broken miner? Maybe it will become clear how that is happening? In the mean time Ill try to reproduce.
My goal is to start payments based on "hashespersec2" that is in the leaderboard, that number is based on shares solved in the current round * difficulty of the share.
Hmm, it seems to be behaving even more strangely now:
Code:
...
5ca54e97-9b69-4468-9fb1-dd6822b2d77f happy_merchant_alt2 982 19999.0000 4199.8638 8/12/2017 1:03:05 PM 41531.6 0.101124531962832 8/12/2017 1:03:05 PM happy_worker: 19848 (41532)
9c899a97-dcab-4871-b01a-1840457d8ec0 happy_merchant 982 19999.0000 3696.2458 8/12/2017 1:03:05 PM 36551.43 0.101124531962832 8/12/2017 1:03:05 PM happy_merchant00: 34910 (36551)
...
4fa6c0db-4f9b-47e1-8a21-3a5fa4450d5d happy_merchant_alt2 981 19999.0000 4199.8638 8/12/2017 1:03:05 PM 41531.6 0.101124531962832 8/12/2017 1:03:05 PM happy_worker: 19848 (41532)
1e4ca98d-dde6-4ec9-a06a-71884d3d8816 happy_merchant 981 19999.0000 3696.2458 8/12/2017 1:03:05 PM 36551.43 0.101124531962832 8/12/2017 1:03:05 PM happy_merchant00: 34910 (36551)
...
9cf804eb-e118-4820-9de0-341eb34a3743 happy_merchant_alt2 980 0.0000 0.0000 8/12/2017 1:03:05 PM 41531.6 0 8/12/2017 1:03:05 PM happy_worker: 19848 (41532)
f51c1fdd-db74-48c2-a9c1-a2f7d91f41c9 happy_merchant 980 0.0000 0.0000 8/12/2017 1:03:05 PM 36551.43 0 8/12/2017 1:03:05 PM happy_merchant00: 34910 (36551)
...
7cbb10ff-2c3e-4d74-991e-b8fc8a301ed4 happy_merchant_alt2 979 19995.0000 4005.9842 8/12/2017 1:02:03 PM 39097.07 0.102462510288904 8/12/2017 1:02:03 PM happy_worker: 19846 (39097)
1188f211-1db7-4495-88aa-f2733cd0b368 happy_merchant 979 19995.0000 3745.1508 8/12/2017 1:02:03 PM 36551.43 0.102462510288904 8/12/2017 1:02:03 PM happy_merchant00: 34910 (36551)
Only happy_merchant00 is connected, but in addition to happy_merchant00 getting credit, happy_worker from my alt account is still receiving credit despite being off-line. The HPS on happy_merchant is also about double what it should be still (it's literally the exact same rig as happy_worker, just changed the workerid in the conf).
The rounds are currently 10 minutes, so it takes 10 minutes to fall out of the round. I think thats OK, as the new shares based system decay function will pay less and less hash per sec as you fall out of the round.
These blocks were solved so fast it literally had the same values it looks like.
August 12, 2017, 01:18:29 PM
Oh ok I see 965 now. Just so you know, I havent switched to paying based on the shares yet, it still pays the same way, but I have the figures on the back end.
Anyway I would really like to debug that happy_merchant high hash payment, do you think you can go back to mining with the broken miner? Maybe it will become clear how that is happening? In the mean time Ill try to reproduce.
My goal is to start payments based on "hashespersec2" that is in the leaderboard, that number is based on shares solved in the current round * difficulty of the share.
Anyway I would really like to debug that happy_merchant high hash payment, do you think you can go back to mining with the broken miner? Maybe it will become clear how that is happening? In the mean time Ill try to reproduce.
My goal is to start payments based on "hashespersec2" that is in the leaderboard, that number is based on shares solved in the current round * difficulty of the share.
Hmm, it seems to be behaving even more strangely now:
Code:
...
5ca54e97-9b69-4468-9fb1-dd6822b2d77f happy_merchant_alt2 982 19999.0000 4199.8638 8/12/2017 1:03:05 PM 41531.6 0.101124531962832 8/12/2017 1:03:05 PM happy_worker: 19848 (41532)
9c899a97-dcab-4871-b01a-1840457d8ec0 happy_merchant 982 19999.0000 3696.2458 8/12/2017 1:03:05 PM 36551.43 0.101124531962832 8/12/2017 1:03:05 PM happy_merchant00: 34910 (36551)
...
4fa6c0db-4f9b-47e1-8a21-3a5fa4450d5d happy_merchant_alt2 981 19999.0000 4199.8638 8/12/2017 1:03:05 PM 41531.6 0.101124531962832 8/12/2017 1:03:05 PM happy_worker: 19848 (41532)
1e4ca98d-dde6-4ec9-a06a-71884d3d8816 happy_merchant 981 19999.0000 3696.2458 8/12/2017 1:03:05 PM 36551.43 0.101124531962832 8/12/2017 1:03:05 PM happy_merchant00: 34910 (36551)
...
9cf804eb-e118-4820-9de0-341eb34a3743 happy_merchant_alt2 980 0.0000 0.0000 8/12/2017 1:03:05 PM 41531.6 0 8/12/2017 1:03:05 PM happy_worker: 19848 (41532)
f51c1fdd-db74-48c2-a9c1-a2f7d91f41c9 happy_merchant 980 0.0000 0.0000 8/12/2017 1:03:05 PM 36551.43 0 8/12/2017 1:03:05 PM happy_merchant00: 34910 (36551)
...
7cbb10ff-2c3e-4d74-991e-b8fc8a301ed4 happy_merchant_alt2 979 19995.0000 4005.9842 8/12/2017 1:02:03 PM 39097.07 0.102462510288904 8/12/2017 1:02:03 PM happy_worker: 19846 (39097)
1188f211-1db7-4495-88aa-f2733cd0b368 happy_merchant 979 19995.0000 3745.1508 8/12/2017 1:02:03 PM 36551.43 0.102462510288904 8/12/2017 1:02:03 PM happy_merchant00: 34910 (36551)
Only happy_merchant00 is connected, but in addition to happy_merchant00 getting credit, happy_worker from my alt account is still receiving credit despite being off-line. The HPS on happy_merchant is also about double what it should be still (it's literally the exact same rig as happy_worker, just changed the workerid in the conf).
August 12, 2017, 01:02:23 PM
Oh really? Could you give me more info, is this still happening now that the new version of the pool is deployed, and if so what block # got paid too much?
Code:
91c85007-5adf-4447-8c03-8d5a9355cd19 Anonymous 965 19999.0000 6.4608 8/12/2017 9:59:03 AM 23600.76 0.000273753441763739 8/12/2017 9:59:03 AM Anonymous
835c5ac2-fff8-4908-8880-0dd189e8dd0b bible_pay 965 19999.0000 6.8437 8/12/2017 9:59:03 AM 24999.68 0.000273753441763739 8/12/2017 9:59:03 AM lastleg: 32246 (25000)
fc358f22-9ae0-4c4d-928b-724f399b2a7e testbible 965 19999.0000 3.4687 8/12/2017 9:59:03 AM 12670.99 0.000273753441763739 8/12/2017 9:59:03 AM testbible: 17256 (12671)
36b54a51-03b0-432c-86cb-f4f1b3aeca0e happy_merchant 965 19999.0000 19982.2267 8/12/2017 9:59:03 AM 72993517.84 0.000273753441763739 8/12/2017 9:59:03 AM happy_merchant00: 28352 (72993518)
Not sure when deployment happened, but this was after changing the worker name character limit.
--edit--
Looks like that worker was also counted for block 966 but the HPS was reported correctly there. Might've been just before you updated.
Code:
d55a9e75-f1c7-4ad6-bea6-1765c9452866 Anonymous 966 19999.0000 4883.8682 8/12/2017 10:14:52 AM 23735.55 0.205761771699916 8/12/2017 10:14:52 AM Anonymous
23528b46-c381-4318-9511-e405860c7a4a bible_pay 966 19999.0000 4703.9429 8/12/2017 10:14:52 AM 22861.11 0.205761771699916 8/12/2017 10:14:52 AM lastleg: 32434 (22861)
abcfc4ab-62a0-4773-94e2-0b67fc40daa9 testbible 966 19999.0000 4102.4177 8/12/2017 10:14:52 AM 19937.71 0.205761771699916 8/12/2017 10:14:52 AM testbible: 17258 (19938)
938a3deb-1f88-408d-8b77-b717a4b920c0 happy_merchant_alt2 966 19999.0000 2881.6733 8/12/2017 10:14:52 AM 14004.9 0.205761771699916 8/12/2017 10:14:52 AM happy_worker: 18680 (14005)
1a0a25a3-9aba-493b-bffe-cd82534446bf happy_merchant 966 19999.0000 3427.0979 8/12/2017 10:14:52 AM 16655.66 0.205761771699916 8/12/2017 10:14:52 AM happy_merchant00: 24314 (16656)
Oh ok I see 965 now. Just so you know, I havent switched to paying based on the shares yet, it still pays the same way, but I have the figures on the back end.
Anyway I would really like to debug that happy_merchant high hash payment, do you think you can go back to mining with the broken miner? Maybe it will become clear how that is happening? In the mean time Ill try to reproduce.
My goal is to start payments based on "hashespersec2" that is in the leaderboard, that number is based on shares solved in the current round * difficulty of the share.
August 12, 2017, 12:52:01 PM
Oh really? Could you give me more info, is this still happening now that the new version of the pool is deployed, and if so what block # got paid too much?
Code:
91c85007-5adf-4447-8c03-8d5a9355cd19 Anonymous 965 19999.0000 6.4608 8/12/2017 9:59:03 AM 23600.76 0.000273753441763739 8/12/2017 9:59:03 AM Anonymous
835c5ac2-fff8-4908-8880-0dd189e8dd0b bible_pay 965 19999.0000 6.8437 8/12/2017 9:59:03 AM 24999.68 0.000273753441763739 8/12/2017 9:59:03 AM lastleg: 32246 (25000)
fc358f22-9ae0-4c4d-928b-724f399b2a7e testbible 965 19999.0000 3.4687 8/12/2017 9:59:03 AM 12670.99 0.000273753441763739 8/12/2017 9:59:03 AM testbible: 17256 (12671)
36b54a51-03b0-432c-86cb-f4f1b3aeca0e happy_merchant 965 19999.0000 19982.2267 8/12/2017 9:59:03 AM 72993517.84 0.000273753441763739 8/12/2017 9:59:03 AM happy_merchant00: 28352 (72993518)
Not sure when deployment happened, but this was after changing the worker name character limit.
--edit--
Looks like that worker was also counted for block 966 but the HPS was reported correctly there. Might've been just before you updated.
Code:
d55a9e75-f1c7-4ad6-bea6-1765c9452866 Anonymous 966 19999.0000 4883.8682 8/12/2017 10:14:52 AM 23735.55 0.205761771699916 8/12/2017 10:14:52 AM Anonymous
23528b46-c381-4318-9511-e405860c7a4a bible_pay 966 19999.0000 4703.9429 8/12/2017 10:14:52 AM 22861.11 0.205761771699916 8/12/2017 10:14:52 AM lastleg: 32434 (22861)
abcfc4ab-62a0-4773-94e2-0b67fc40daa9 testbible 966 19999.0000 4102.4177 8/12/2017 10:14:52 AM 19937.71 0.205761771699916 8/12/2017 10:14:52 AM testbible: 17258 (19938)
938a3deb-1f88-408d-8b77-b717a4b920c0 happy_merchant_alt2 966 19999.0000 2881.6733 8/12/2017 10:14:52 AM 14004.9 0.205761771699916 8/12/2017 10:14:52 AM happy_worker: 18680 (14005)
1a0a25a3-9aba-493b-bffe-cd82534446bf happy_merchant 966 19999.0000 3427.0979 8/12/2017 10:14:52 AM 16655.66 0.205761771699916 8/12/2017 10:14:52 AM happy_merchant00: 24314 (16656)
August 12, 2017, 12:22:05 PM
Whew, 72 MH/s. Yeah, it's looking like all workers on the happy_merchant account are bugged now.
I'll swap over to an alt account until the shares system is updated.
Oh really? Could you give me more info, is this still happening now that the new version of the pool is deployed, and if so what block # got paid too much?I'll swap over to an alt account until the shares system is updated.
August 12, 2017, 12:20:45 PM
I see a lot of progress here. Any ETA for pool mainnet launch date?
Will update a little more in an hour but from a very high perspective, today was a great day, deploys getting made now so we can test again with the shares system. I believe we had a bug on the pool side.
Im just guessing but I think within a few more days, we might be able to test out prod.
We must test the windows client against the pool now.
Happy, I just released a new version of the pool, this has the shares calculation showing up in "Leaderboard".
August 12, 2017, 10:13:09 AM
I see a lot of progress here. Any ETA for pool mainnet launch date?
August 12, 2017, 10:07:05 AM
Whew, 72 MH/s. Yeah, it's looking like all workers on the happy_merchant account are bugged now.
I'll swap over to an alt account until the shares system is updated.
I'll swap over to an alt account until the shares system is updated.
August 12, 2017, 08:40:00 AM
Another weird thing that I've been wondering for a while now. The network_khashps reported by getmininginfo seems to be off. Right now for example it's saying 465 kh/s. Adding the values from the pool, it should be around 60-70 kh/s. It's possible there's a miner or two on the test chain who aren't in the pool, but it's definitely not 400 kh/s worth of non-pool miners since the pool is finding every block.
Yeah, I see our 4 miners overnight were doing about lets say 80khps, and the getmininginfo for the network shows 440khps right now, and I agree probably only 1-2 stragglers out there solo mining max, that would bring it to 100khps.Let me audit the c++ code now and Ill get back to you.
Thanks.
August 12, 2017, 08:16:29 AM
Withdrawal and anonymous works fine. Hash rate is close enough.
August 12, 2017, 08:14:26 AM
The pool backfilled the block_distribution back in automatically without your worker, but after you recreate it you should be back on, but yes, if this happened in prod, I would need a procedure to back out the money also from the users, and in testnet you still got credited.
Yeah, that's definitely a benefit of having an immature balance system. If a bug popped up or someone blatantly tried to exploit on live, there'd be time to revoke their credit and redistribute the reward before they pulled it out of the pool.
August 12, 2017, 08:08:43 AM
Another weird thing that I've been wondering for a while now. The network_khashps reported by getmininginfo seems to be off. Right now for example it's saying 465 kh/s. Adding the values from the pool, it should be around 60-70 kh/s. It's possible there's a miner or two on the test chain who aren't in the pool, but it's definitely not 400 kh/s worth of non-pool miners since the pool is finding every block.
Yeah, I see our 4 miners overnight were doing about lets say 80khps, and the getmininginfo for the network shows 440khps right now, and I agree probably only 1-2 stragglers out there solo mining max, that would bring it to 100khps.Let me audit the c++ code now and Ill get back to you.
Jump to: