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

[bible_pay]

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)

Also looks like I got about a 50% extra payout for block 966 by swapping accounts midway. Will check if that happens in block 979 too since I just swapped accounts again.

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.

[1714120014]

1714120014

[happy_merchant]

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.

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

[bible_pay]

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.

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.

[happy_merchant]

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.

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.

[bible_pay]

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.

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?

[bible_pay]

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.

[happy_merchant]

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?

Running Windows on the machine I'm using for the testpool.

[splinky]

Wow, looks like a lot of hard work is going into this! Definitely looking forward to having the pool fully up and running!

[bible_pay]

All- I did a bad deploy - please hang on, Im working on fixing it now.

[bible_pay]

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.

[bible_pay]

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)

[jaapgvk]

Hi,

I've been mining this coin for a few days (first time I've ever mined a coin). I really like this project and would like to help you by also mining on the testnet. But the version on the site still seems to be 1.0.1.9? I tried both the 32-bit and 64-bit version.

[bible_pay]

Hi,

I've been mining this coin for a few days (first time I've ever mined a coin). I really like this project and would like to help you by also mining on the testnet. But the version on the site still seems to be 1.0.1.9? I tried both the 32-bit and 64-bit version.

Your right, I see the problem.  So when our major version flipped from 1.0.1.4-1.0.1.9, we had no problem.
At 1.0.2.0, there is a problem.

Hang on.

[bible_pay]

Hi,

I've been mining this coin for a few days (first time I've ever mined a coin). I really like this project and would like to help you by also mining on the testnet. But the version on the site still seems to be 1.0.1.9? I tried both the 32-bit and 64-bit version.

Your right, I see the problem.  So when our major version flipped from 1.0.1.4-1.0.1.9, we had no problem.
At 1.0.2.0, there is a problem.

Hang on.

Ok, 1.0.2.0 is out there now.

Good luck.

[happy_merchant]

It seems to be very reliable now for mining on a single worker now. Even swapping on and off different workers seems to behave as expected.

I'm pretty sure there's something weird going on with multiple workers on one account, though. Your bible_pay account is only earning about twice as much as jaapgvk despite putting out over 4 times his hash rate. I could understand if it was occasional and he just got a lot of shares that round, but it seems to be every block.

Running some tests now to quantify it a bit better. Running two rigs as two workers under one account right now, going to give it another 10 or 20 blocks then change it so the same rigs are mining on separate accounts, then compare the rewards.

Also, I think the network_khashps is reporting much too low just by comparing it to the pool hash rate. I'm guessing you implemented some of the changes you mentioned the other day?

[bible_pay]

It seems to be very reliable now for mining on a single worker now. Even swapping on and off different workers seems to behave as expected.

I'm pretty sure there's something weird going on with multiple workers on one account, though. Your bible_pay account is only earning about twice as much as jaapgvk despite putting out over 4 times his hash rate. I could understand if it was occasional and he just got a lot of shares that round, but it seems to be every block.

Running some tests now to quantify it a bit better. Running two rigs as two workers under one account right now, going to give it another 10 or 20 blocks then change it so the same rigs are mining on separate accounts, then compare the rewards.

Also, I think the network_khashps is reporting much too low just by comparing it to the pool hash rate. I'm guessing you implemented some of the changes you mentioned the other day?

Thanks on point #1, great.
Yeah, I think on the networkhashps, I convinced myself that it needed changed, and in actuality, it appears it should be  changed again, now I think it should have been done this way:

getnetworkhashps 1114 1121 (startblock endblock) with approximately 8 block skips (thats supposedly a little over an hour)

That yields:
169.455075673734 while the pool is currently at 135khps, that seems more sane.

Going back through the chain, for instance with 500 510, it decreases what appears to be appropriately, then around the time of genesis to 100, its really low.  I think that is the problem.  Let me update the code, and I will get back on the rest of the testing issue, thanks for bringing this to the forefront.  Once we release it, this should be relatively easy to check in prod against the bx, I think.

[bible_pay]

It seems to be very reliable now for mining on a single worker now. Even swapping on and off different workers seems to behave as expected.

I'm pretty sure there's something weird going on with multiple workers on one account, though. Your bible_pay account is only earning about twice as much as jaapgvk despite putting out over 4 times his hash rate. I could understand if it was occasional and he just got a lot of shares that round, but it seems to be every block.

Running some tests now to quantify it a bit better. Running two rigs as two workers under one account right now, going to give it another 10 or 20 blocks then change it so the same rigs are mining on separate accounts, then compare the rewards.

Also, I think the network_khashps is reporting much too low just by comparing it to the pool hash rate. I'm guessing you implemented some of the changes you mentioned the other day?

Addressing the 2nd point, why a dual miner on one acct is paying less total % perblock than JaapGs single miner:
Its actually not really the two miners themselves summed, its the hashpersec2 root assessment.  I do see what would appears to be a problem on block distribution block # 1114.  In parentheses (thats the hashpersec2 assessment) I clocked in at 40.7k total for both while jaapg clocked in at 19.3k (the payment distribution is obviously OK), but honing in the issue is why did he get half while I was doing 80kh on the pc side (the original hashpersec) with him only doing 18k on hashpersec (thats 4* the hashes in reality)?  The answer lies in the hashpersec2 calculation.  It has a decay factor built in to prevent pool hopping and assigns more weight to more recent solved shares.  I cant find a way to eliminate it and I would assume it would even out over time- but then we have to see.

Looking at 1119 I came back with about 3* the payment but its still a little low, relative to Jaap, then on 1121, it looks like it went south again.  Im wondering how can Jaap always achieve such short term solutions? It could be his machine is solving easier hashes. (Ill take a look at the tables on his miner).

We can either wait and see if it averages out, or go deeper into it.
It might be an issue.

[jaapgvk]

I'm pretty sure there's something weird going on with multiple workers on one account, though. Your bible_pay account is only earning about twice as much as jaapgvk despite putting out over 4 times his hash rate. I could understand if it was occasional and he just got a lot of shares that round, but it seems to be every block.

I've haven't really been tinkering around or anything. Mostly been mining constanty with around 20 khashps. But i tried a few things. I tried mining with one thread. And I also stopped mining for a few blocks (around 1114-1118) and then started again. Before stopping, I think the distribution was as expected, and after starting again, it seems the pool has to 'rebalance' for a few blocks it seems (I have never mined in a pool before, so I have no idea if what I'm saying makes any sense). But I'll see in the next couple of blocks what will happen...

EDIT: at approx block 1110 went from mining with 4 threads to mining with one thread. 30 minutes later I switched back to 4 threads. And 20 minutes later i stopped mining.

If you'd like a log or anything, just tell me how to make one and I'll post it here

[bible_pay]

Oh ok 10-4 guys, well scratch (most) of what I said earlier, there was a bug in the value carried over into the block_distribution when you have more than one miner on the account!  So now it makes much more sense.

I deleted the last 3 blocks and let them re-pay and now they look pretty sane.

May we Charge forward now!

[happy_merchant]

Oh ok 10-4 guys, well scratch (most) of what I said earlier, there was a bug in the value carried over into the block_distribution when you have more than one miner on the account!  So now it makes much more sense.

I deleted the last 3 blocks and let them re-pay and now they look pretty sane.

May we Charge forward now!

Ah, I was tracking the HPS and noticed that it started looking correct for multiple workers all of a sudden.

The pool is starting to look pretty good. Hopefully we can get some more people to jump on testnet once it's close to release to stress test it a bit.