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) |
|
|
|
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. |
|
|
|
|
All- I did a bad deploy - please hang on, Im working on fixing it now.
|
|
|
|
|
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.
|
|
|
|
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? |
|
|
|
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: ...
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. |
|
|
|
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?
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. 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. |
|
|
|
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 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". |
|
|
|
Correct, but in reality there are about 144 blocks every day which is 10 minutes mean block time. Edit: Here's happy_merchant's post if you missed it: @bible_pay: Could you maybe explain the fact that only ~70% of blocks are found each day?
26928 minutes / 2675 blocks = 10.0665 minutes/block18 days is not a long enough sample time to make the assumption that the parameters are failing. I believe there was a discussion early on in litecoins thread that it took about a year for the diff retarget to average out. However, I do want to ensure we start retargeting our diff every single block (instead of 4 as it is currently), and decrease our stuck blocks down to 30 mins during the next mandatory. We have quite a few slow blocks, and that will drag this short sample period up significantly. |
|
|
|
I'm not sure if I understood that correctly, but here I pasted the same log for block 2782, only this time with the surrounding blocks so you can see more info. I highlighted the time stamps which I think are related to the block 2782 in yellow, and the ones which are related to the block 2783 in green. 2017-08-12 08:30:45 UpdateTip: new best=000001631b73838c0fbb1c77726900fca1326f7ed687722ba68664da2b20e66e height=2781 log2_work=32.422993 tx=3307 date=2017-08-12 08:30:33 progress=0.999996 cache=0.0MiB(116tx)
2017-08-12 08:30:45 ProcessNewBlock : ACCEPTED
2017-08-12 08:30:51 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done
2017-08-12 08:39:48 UpdateTip: new best=00000024a3327afa5e3ff620607e48841ec35c6a92a554a132e0dbb616b5526d height=2782 log2_work=32.427115 tx=3308 date=2017-08-12 08:39:47 progress=1.000000 cache=0.0MiB(117tx)
2017-08-12 08:39:48
** TestBlockValidity FAILED - pindexNew->pprev != chainActive.Tip() (assert(pindexNew->pprev == chainActive.Tip())); **
2017-08-12 08:39:48
BiblepayMiner -- runtime error: CreateNewBlock: TestBlockValidity failed: (code 0)
2017-08-12 08:39:48 ProcessNewBlock : ACCEPTED
2017-08-12 08:39:55 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done
2017-08-12 08:59:25 UpdateTip: new best=000000018734cbb6422e82aeaa2f52162760f95ea4d485a2a5c8de3a46bc47b9 height=2783 log2_work=32.43188 tx=3309 date=2017-08-12 08:59:25 progress=1.000000 cache=0.0MiB(118tx)
2017-08-12 08:59:25 ProcessNewBlock : ACCEPTED
2017-08-12 08:59:31 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done
2017-08-12 09:57:59 UpdateTip: new best=00000156f9db92abe88a4de4462004df12893c6b4718e8daca291ef06e765eb1 height=2784 log2_work=32.434599 tx=3311 date=2017-08-12 09:57:59 progress=1.000000 cache=0.0MiB(7tx)
2017-08-12 09:57:59 ProcessNewBlock : ACCEPTED
2017-08-12 09:58:05 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done So I don't understand what does block 2783 have to do with the error which appeared in the yellow timeline, because that block was found in the green timeline 20 minutes later. Unless you mean it was supposed to be found by the miner back then, but the error always appears in the same second as the UpdateTip for the previous block. Hi Inblue, Looking at 2782 and 2783 and the timeline, it is OK if 2783 was actually solved 20 minutes later, what appears to be happening is this (I can say this based on the TestBlockValidity context): 2782 is accepted at 2017-08-12 08:30:45 2783 is accepted at 2017-08-12 08:59:25 In between these timestamps, at 08:39 AM, One of your mining threads throws a ** TestBlockValidity FAILED. So you are alluding to the possibility that the miner could not create a new block, but yet the tip had no reason to be updated as a block didnt arrive until 20 minutes later. Its possible createnewblock is affected by many competing threads, possibly a mutex issue causing a missing pindexprev pointer. We can add more logging in createnewblock and try to find out why occasionally, the miner can not create a new block, and that results in testblockvalidy failing. It looks like it is unrelated to network activity, orphans, reorganizations, and only the actual activeChain.tip, because the tip was not changing on the node. So it really appears the createnewblock is sometimes in a blue moon returning a new block with a missing pindexprev pointer, or something to that effect. It might be revealing for us to put in a little busy wait loop right when that occurs for 7 seconds and log info about the chainactive.tip before throwing the error, just to see if the node recovers its tip by itself. I will add that to my todo list. |
|
|
|
I also found the 205 blocks per day parameters in the code, so I am very worried about this, there's definitely something strange here and I hope it's not very complex to fix.
Real quick on the 205 blocks per day, nothing to be worried about that is correct: 60/7*24 205.7 HH/7Min Blocks * 24 Hrs per day = 205.7. The integer is fine, its just an input for diff retargets, and lookback functions such as the gather prayers per week, etc. Nothing looks awry. I am still checking the rest of your post |
|
|
|
** TestBlockValidity FAILED - pindexNew->pprev != chainActive.Tip() (assert(pindexNew->pprev == chainActive.Tip())); **
Regarding mining in general and seeing this error in the log: First, it is normal for the miner to be stuck in a busy-wait loop busy hashing the current block, while the chainActive.Tip() moves on to a new block, and occasionally, for some reason in AcceptBlock it is possible right at a microsecond instant that the main wallet thread is assigning the pindexNew->pprev to something new, pindexNew->pprev to the miner is NULL, and this results in the miner throwing an error and having to go start over and CreateNewBlock. This part of it is absolutely normal and as long as it is happening about once every 4 hours or less, no harm is being done and the miner is not slowing down. The wallet Is set up with the correct parameters, and handling this condition, but The main stress I want to make on this is that we ensure these things: 1. If the wallet is set up with 10 mining threads to begin with, each thread is handling that particular error and still mining at the end of the day. (Check this). 2. The wallet does not crash. 3. The HashPs of the Box itself should bear out a similar value as when the day started. If #3 especially is true, then everything is fine. I would suggest grabbing a baseline hashps from the box 5 min after start, and then checking on it 24 hours later. If the hashps is the same, then dont worry about the error as long as its very rare in the log. One additional note, if you turn on too many debug switches, the box gets busy just writing the Logs! So after we are stable we need to focus on not logging everything in non-debug mode as that can slow down the miner. Thanks. |
|
|
|
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. So looking at the networkhashps calculations, it appears the underlying chain work is accurate in each block, and the calculation model itself, that averages the networkKhasPs over time looks solid. The issue comes into play where there are two versions of the function that regresses back to the last diff change. One version appears to have the parameters passed in backwards, (not by me, just by the unusual parameter we have set up in the consensus which by themselves are correct for DGW but dont translate to BTC) and the other, well it looks like the defaults calculate something entirely wrong, so either way we need a code change. So anyway, I ended up doing some calculations and found generally, what works pretty good is our BLOCKS_PER_DAY divided by 24 hours (that means we would see the NetworkKhashPs over the last hour). You can simulate this by doing a getnetworkhashps 960 951 and now we end up with a 31khps, which seems right. I went back through the chain when I was solo mining, for example getnetworkhashps 50 40, and you can see it drop to .01 etc, so this appears to be correct now. I am modifying the code so this will be in the next release. Thanks. |
|
|
|
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. |
|
|
|
Also, there were a couple times tonight that logging in to the pool website failed. No errors or anything, you just click login and the page reloads but you're not logged in. It's currently happening at 5:11 AM PST.
Oh my another morning of IT issues! Thanks for all the help btw. So, on the long miner name itself, I added a length restriction of 19 chars to the page and deleted your worker, so please recreate it. I dont know why the hashPS join subsystem was calculating your hashes wrong. Im still tweaking the shares anyway, so its moot to even fix that. Let me try to get that working so we can test that new system. 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. Regarding the inability to log in, by the time I woke up, the system was back up. Ill look at the logs. Something is causing the microsoft app pool to crash, and then when the 'down' elapse period is exceeded, it brings itself back up. I assume mining is still occurring at that time. |
|
|
|
There are over 500 connections on my external node; that leads me to believe by 500 distinct users, thats where they are going.
Happy_merchant should be able to help answer, that would mean that the block explorer will show distinct keys for almost every block.
Well, about all I can say is that roughly half of all BBP in existence is being held in receiving addresses that hold 40k or less BBP. But, I'm sure a lot of the major holders haven't consolidated all their BBP under one address, so it's hard to say how many users that represents. The Biblepay node for the block explorer has capped out at 500 connections a couple times, although there's only 153 right now probably since the daemon crashed a few hours ago and had to be restarted. Personally, I'm not seeing any major issues with the rewards on my miners. I started mining the day after Biblepay launched and I've gotten 42 blocks. So, a very rough estimate would be: 42 / (2671 - 267) = 0.0175 = 1.75% The "- 267" is because every 10th block is automatically assigned to the orphan wallet. Since I actually missed out on a days worth of mining at the start, the percentage should actually be a little higher. I'm currently contributing a little bit over 2% of the network hashrate and that's pretty consistent with what I've been contributing at other points when I checked. Considering that I haven't had 100% uptime on my miners, mining 1.75% of the blocks seems pretty reasonable, and the sample size is large enough that it should be meaningful even if it's an estimate. If there is a problem somewhere, it'll be obvious when the pool goes live. The pool will likely make up a huge percentage of the network hash and we'll be able to track every block it mines. That'll provide a very accurate source of statistical data. Thanks for the good analysis! |
|
|
|
I've come across wallets with built in pool mining that had a gui interface to start/stop and even included a default pool. Would it be possible once the pool mining is implemented to bring over that function?
Yeah, actually, we could put an auto-config menu option in the wallet to make it easier to set up the default pool. Then we can put in a start/stop menu item also to make it easier to solo or pool mine without doing much work. Thats a good idea, anything that adds value to the wallet could be good for our long term staying power. |
|
|
|
[...] every 10th block is automatically assigned to the orphan wallet. How does this work exactly? Miners do not get the reward even though they found the block? If that's the case, I share your opinion that it would be better to take 10% from every block, because of the reasons you explained earlier. @bible_pay: Could you maybe explain the fact that only ~70% of blocks are found each day? 90% of the block rewards go to the miners. We drop the difficulty to mine the tithe blocks by 80% (hardcoded in the wallet, in the dark-gravity-wave diff function), so they just fly by and no one really has to do much work. |
|
|
|
Yeah, the current pool does try to take account HPS on miners that pool hop, but the synthetic HPS of the pool is not always accurate per block- but I think over time it would be a good average. The payout for 773 was based on 8763 hash ps, but your _alt miner generally did about 10500 hash ps. I wonder if you worked on at least 50% of the block or if you really got lucky. I also wonder, how many threads are you running on this miner?
Was only mining on happy_merchant_alt for less than 5 minutes out of the 55 minutes for that block, so it definitely wasn't 50%. Just running 1 thread on my pool miner. I took a look at the logs, and I believe the issue is on the pool side predominantly, but what happens occasionally, is the threads on the miner side get tied up with work that is too hard to solve for longer than the duration of the block, and 0 shares are submitted by the miner that count toward the block, even if the miner submitted the solution, the stats didnt update in time before the block was solved and paid.
I don't know if it's relevant, but it hasn't happened since I swapped pool accounts. It was happening pretty frequently before, but now it's been over 40 blocks without dropping any. The miner is identical, I just changed the worker_id. Also, I didn't notice it happening before I spammed all those withdrawal transactions, so I'm wondering if maybe something in that account got corrupted. Going to keep mining on my alt account for a while to verify that it's not happening, then I'll try swapping back again. Oh ok, well I do know that the current version of the pool doesnt work as well with one thread (although I dont want to encourage a huge number of threads as that would saturate the pool) but anyway, with one thread, I can see falling out of the block, as if that one thread gets tied up with work it could miss a block. Maybe try 4 threads or so? |
|
|
|
|
Show Posts
