|
So on the ST13 error, I see we have a line of code for DGW that is strictly used to log to the screen and it could potentially be causing the ST13 error.
I commented that out, and pushed 1.0.3.3 out. Anyone on Linux that has this ST13 error, please upgrade to 1.0.3.3 and let us know if that fixes the ST13 error.
Ill build a new version of Win just in case.
I have to run a few errands, windows is building now.
Regarding the Ban issue: This new version will ban 1031 and down, because the subsidy is higher. We will just have to wait until everyone upgrades to 1033 to test the ban issue to make sure its gone.
|
|
|
|
Got a Runaway Exception pop up on two of my boxes so far (Win7) on Windows 64bit file. "A fatal error occurred. Biblepay Core can no longer safely continue and will quit." Debug file : EXCEPTION: St13runtime_error tinyformat: Not enough conversion specifiers in format string C:\Program Files\BiblepayCore\biblepay-qt.exe in Runaway exception 2017-09-13 15:52:44 CDBEnv::EnvShutdown: Error 22 shutting down database environment: Invalid argument I believe this happens when you Kill your client without pressing File | Exit. Try restoring wallet.dat and tell me if it comes up? EDIT: Also, tell me if your biblepay.conf file is corrupted? |
|
|
|
Well explained, like Blu I'll have to re-read it again to get a complete understanding. But I would echo his request on versions, if there would be a way for the Core to report what OS was used, it would be very interesting to know and could lead to some improvements. Thanks as always for your attention and willingness to work that keeps this coin moving forward.
Yeah, I think what we can do is during the init.cpp, we can determine if its Win (as code exists to choose the windows tcp stack), linux (as we know its not win and not mac), or MAC. And set a variable globally. Then when the user hits the pool, relay the client version and the OS. This would be useful to allow the pool to collect user baseline. Then later we can expose a report in the pool to show the % by OS flavor. I think we can do this. |
|
|
|
sorry to say , but 1.0.3.2 on linux is dying the same way as 1.0.3.1 . have to follow the same routine restarting the daemon  Im not sure I completely understand, what is dying and restarting which daemon? (I know we always restart the daemon), and Im dealing with many spinning errors, not sure what you mean about 'dying'. |
|
|
|
************************
EXCEPTION: St13runtime_error
tinyformat: Not enough conversion specifiers in format string
biblepay in ProcessMessages()
2017-09-13 15:34:23 ProcessMessages(block, 191 bytes) FAILED peer=1
2017-09-13 15:34:23 89
************************
I got this error in 1.0.3.2 in debug.log, repeated many times, and it stopped syncing after that. The error started right after block 7099 has been synced. I am getting a similar error with Windows 32 bit v1.0.3.2 exe 2017-09-13 15:32:59 init message: Activating best chain...
2017-09-13 15:32:59
************************
EXCEPTION: St13runtime_error
tinyformat: Not enough conversion specifiers in format string
C:\Program Files (x86)\BiblepayCore\biblepay-qt.exe in Runaway exception
2017-09-13 15:33:02 CDBEnv::EnvShutdown: Error 22 shutting down database environment: Invalid argument
2017-09-13 15:34:21 Checking, but in the mean time I vaguely remember this happens when the wallet cant open the wallet.dat file. Please try restoring a backup of wallet.dat from the backups folder and let me know. |
|
|
|
Is there a new wallet out¿
The linux is checked in, but Im waiting on Win to compile. Probably 30 more minutes, then Ill post a mandatory upgrade. |
|
|
|
Correct, exactly, you nailed it. Well, ideologically I guess it's not bad to favor the mid to small miners for high decentralization purposes, but I am still wondering from the technical side of things, is that a bug in the algo or something.
Alrighty a guess and some homework for you is all I can offer on this today: So the old algorithm had an outer loop of 1000 X11 hashes and an inner loop of one biblepay hash, meaning that if you ran 80 threads on x11-bbp pre F7000, that distributed thread could conduct its hashing without the resources of the full node. (Whenever the miner needs to access the resources of the full node, for example, asking it for AES/md5/chaining the KJV together) grabbing the pindex bestblockindex map, it is in a way locking the thread for a few milliseconds and grabbing its data and then continuing. In the NEW world, in F7000, its hashing only one X11 hash (for the blockindex), yet 1000 BibleHashes of work being expended per loop. So its no longer able to decentralize a thread with just a math problem (IE x11 solution), and come back and join the rest of the threads, instead, its doing a lot of biblehash->askfullnode->biblehash->askfullnode, etc. So my guess is this: In f7000, there is a strong reliance on the full nodes availablility, and the thread itself can only do so much work before its waiting around for availablility of the data it needs (like a blockindex for example, from the map). The reason the kernel cant allow two threads to read the same value simultaneously is that would cause a segfault error. So what I recommend is this: Find a way to run multiple copies of biblepay on one server, and do a side by side comparison of those specs with the sum of the hash of biblepay instances. If the hash throughput is higher on the multiple copies, then we know that I said above is true and the only way to consolidate hardware to high power servers is then to run multiple instances per node. On a side note if we find that to be the case then that is good- as you said earlier -part of the benefit of requiring the full node is to reward the decentralized full node environment (IE not the people with the biggest nodes) as part of the original vision is to not be greed based but to be service oriented. |
|
|
|
I get it. Do you happen to have the info on how many Windows users there are, compared to the Linux users?
This is just a guess, since I dont have those figures, although that brings up a good point, that we should make an attempt to grab those figures for development purposes. Based on my experience with other coins, believe it or not, its usually an 80% windows download rate, 20% linux (1% mac). However, I believe with BiblePay, we have a handful of grass-root linux supporters who seem to run a high quantity of nodes (IE they seem to have excess money laying around for hobbies, and/or have some relationship to cloudmining). We might be attracting people who deal with excess PC resources, being the only coin that hasnt been exploited by GPUs. Anyway, Im going to guess that out of 750 users, 70% are still PC users, but I believe personally that if you went with node count, we would be along the lines of 1000 nodes with 50% being linux nodes... So the linux count is probably skewed due to ROI and huge quantity per hobbyist. (There are stories on the internet of some coins that tried to launch as linux-only, and they always died.) |
|
|
|
Please be ready for a mandatory upgrade in 4 hours.
I was born ready.  Awesome work, very fast. I see 1.0.3.2 is already on GitHub, so we can start the upgrade? Lets give it a couple hours at least, so the windows users have a "chance" to come online. This way we can all sort of get in together. Do you know when the Windows version will hit the website to DL? The reason I ask is that Endpoint Antivirus (my workplace's choice for antivirus) has red flagged the 64 bit version's download link (not the file but the link) so I have to go through a bunch of fun phone gymnastics to get it downloaded and copied over here. I will do a git pull for linux at 10AM and start the recompile, that should give some time. I think it will be ready in about 90 minutes, it looks like its halfway done compiling. I see c-cex is still down for maintenance; hopefully they had a lot of unrelated work to do. Probably reindexing the database. |
|
|
|
Please be ready for a mandatory upgrade in 4 hours.
I was born ready. Awesome work, very fast. I see 1.0.3.2 is already on GitHub, so we can start the upgrade? Lets give it a couple hours at least, so the windows users have a "chance" to come online. This way we can all sort of get in together. I started linux upgrades. they will take at least an hour anyway . thanks Bible_pay Yeah, "make" takes around half an hour on high spec machines. Is there a way to only build changed files, like src/main.cpp and src/pow.cpp? lunux miners deserve some bounty for the troubles with babysitting 1.0.3.1 : ) At least linux users can make a script to upgrade easier than the windows users. Its probably going to be necessary anyway if you want to run multiple masternodes. |
|
|
|
Please be ready for a mandatory upgrade in 4 hours.
I was born ready. Awesome work, very fast. I see 1.0.3.2 is already on GitHub, so we can start the upgrade? Lets give it a couple hours at least, so the windows users have a "chance" to come online. This way we can all sort of get in together. I started linux upgrades. they will take at least an hour anyway . thanks Bible_pay Yeah, "make" takes around half an hour on high spec machines. Is there a way to only build changed files, like src/main.cpp and src/pow.cpp? On my debian box, I do partial non-clean builds, and all I do is run a script that does the git pull origin master, then I skip over to 'make' (dont configure or autogen), and it builds a lot faster. |
|
|
|
Please be ready for a mandatory upgrade in 4 hours.
I was born ready. Awesome work, very fast. I see 1.0.3.2 is already on GitHub, so we can start the upgrade? Lets give it a couple hours at least, so the windows users have a "chance" to come online. This way we can all sort of get in together. |
|
|
|
BTW 5k coins of reward per block on pool and huge drop of hash is worth of mine for small miners...
@inblue what is your best cpu on witch you got such big hash?
Ahh... This is another topic I wanted to start, but I was too lazy. There are obviously some big changes in this new algo in ways I still don't quite understand. It seems that the algo actually favors mid-range and small miners, because stronger machines don't bring proportionally as much HPS2 (real HPS measured by pool). Now it's much better to have 10 small machines which have 8 threads each than to have 1 big machine which has 80 threads. Here is a rough comparison of my miners: blu1 = 16 cores, genproclimit 32, 64k HPS, 42k HPS2 blu2-3 = 24 cores, genproclimit 48, 64k HPS, 42k HPS2 blu4 = 40 cores, genproclimit 80, 55k HPS, 27k HPS2 blu5-9 = 2 cores, genproclimit 8, 17k HPS, 35k HPS2 First of all, why do blu2 and 3 have the same hashrate as blu1? In the previous algo they had about 530k while blu1 had about 350k, and these numbers are exactly proportionate to the number of cores (24 cores = 530k hps, 16 cores = 350k hps, divide them and you'll see, about 22k per core). Now both the 16 core one and the 24 core ones have the same hashrate, as if the CPU on the 24 core machines is not used to its fullest, but it is, it has 100% usage. But the real mystery here is how in the world does a $20/mo shared VPS (blu5-9) outperform a $250/mo dedicated enterprise machine (blu4)? In the previous algo the high-spec machine was at the top of the leaderboard at around 830k hashrate and the cheap VPSs had around 70k each. I can answer Part of this, but not entirely sure where the rest of the answer lies. So the HPS2 column should not be brought into the equation in this case, because the pool is paying per Share found per round now, and HPS2 is now based on shares found in the round (Its something like shares found * 1000 * AgeDecayFactor) . So that column contains a bit of luck. Every share is equal also, so the higher power machines should be finding a proportionately higher number of shares. But moving on, you show that the $20 blu5-9 hashed at 70k in the prior algo, now at 17k, and the $250 blu4 hashed at 800k prior and now at 80k. Meaning that before, you had received 12* the reward for the $250 server, and now you only receive 4* the reward (making the $20 equal to $80 per month, or, an extremely bad ROI). Yes, I see what you mean, the current algo is favoring the mid to small size machines. So unless you disagree it sounds as if we should talk about why does the new algo favor the mid to small machines, correct? |
|
|
|
|
I decided to go ahead and fix these 3 known issues (including raising the subsidy back to the 18000 level - so we dont confuse investors with any uncertainty), while c-cex is down.
This next release should solve the subsidy, the pool-ban issue, and the read from disk error. The x11/checkblock issue will be resolved based on all users running the new version.
Please be ready for a mandatory upgrade in 4 hours.
|
|
|
|
I've just taken a look at my workers for the first time today and it appears all my workers have been down for sometime. Restarting the daemon (I'm on linux) doesn't restart mining; something is wrong. I nuked one of the instances of biblepay that I have by deleting .biblepaycore (except biblepay.conf) and let the blockchain resync. Once sync'ed, it won't mine and gives "HEALTH_DOWN" when I check 'getmininginfo'.
Here's the latest extract from 'debug.log':
------
2017-09-13 06:17:27 ERROR: CheckBlockHeader(): proof of work failed
2017-09-13 06:17:27 ERROR: ProcessNewBlock: CheckBlock FAILED
2017-09-13 06:17:27 Misbehaving: 45.76.85.130:40000 (50 -> 100) BAN THRESHOLD EXCEEDED
2017-09-13 06:20:53 ERROR: ReadBlockFromDisk: OpenBlockFile failed for CBlockDiskPos(nFile=-1, nPos=0)
2017-09-13 06:20:54 89ERROR: CheckProofOfWork(): BibleHash does not meet POW level with TxIndex Lookup, prevheight 7141.000000 pindexPrev 16265e604f37754bec$
2017-09-13 06:20:54 ERROR: CheckBlockHeader(): proof of work failed
2017-09-13 06:20:54 ERROR: ProcessNewBlock: CheckBlock FAILED
2017-09-13 06:20:54 Misbehaving: 149.56.43.244:57462 (0 -> 50)
2017-09-13 06:20:54 89ERROR: CheckProofOfWork(): BibleHash does not meet POW level with TxIndex Lookup, prevheight 7142.000000 pindexPrev be3a96f7b585a3c6e3$
2017-09-13 06:20:54 ERROR: CheckBlockHeader(): proof of work failed
2017-09-13 06:20:54 ERROR: ProcessNewBlock: CheckBlock FAILED
2017-09-13 06:20:54 Misbehaving: 149.56.43.244:57462 (50 -> 100) BAN THRESHOLD EXCEEDED
------
Reading the previous posts, this isn't quite the same as what other people have reported. I 'clearbanned' like someone else mentioned, but it doesnt seem to change anything. 'Thoughts?
I have both of these problems lol. My miners constantly go off the pool and I think they are not reverting to solo mining, because it still says poolmining=true, but the pool doesn't recognize them. When I restart them, they go on the pool briefly and then drop again.
Same problem for me since yesterday. Been pulling the miners online every half hour before they go offline. Doesn't switch to solo mining either. Dev is doing a great job but wish all the changes such as algo, difficulty adjustments etc were first tested on the testnet first before multiple mandatory fixes. Also not sure what the pool's reward system is like right now, seems erratic. @bible_pay Any chance of fixing the difficulty adjustment sooner, the difficulty is increasing exponentially and block rewards are at 25% now. Yes, I agreed that fixing of block rewards should be the top priority, because it is too low now. And I would think after this lesson, dev really have to test any changes in testnet before release it, there are too many unknown issues occurred. I don't mean to criticize and I really appreciate dev's effort, I think dev must be busy on fixing these issues now Glad all of us are agreeing on this. Dev is doing a tremendous job, his openness and commitment to the project is the reason I started engaging with BiblePay in the first place. Hope the dev finds time to get through these fixes.  Alright all, well Im not against sending out a mandatory upgrade that fixes these current issues - since c-cex hasnt upgraded the mandatory yet. Regarding testing in testnet, we DID test in testnet, but these outlying conditions were not caught. I think what we need to do is during the next testing phase, we need more volunteers (we only had a few faithful volunteers last time) and we need to have more elaborate test cases. Moving forward, I agree, the subsidy was a big surprise and its getting worse. The node ban problem is an issue also. Why dont we take advantage of this period while the exchange is down and fix the 3 known issues, have a mandatory and then follow up with c-cex. I see they are down for maintenance now, they will probably be taking BBP offline in 20 mins. I just ran a simulation on the current diff level, and I am positive of the new value that we need compiled in to put our subsidy back around the 18000 level, so that is solved. The banning issue in prod is solved with a high degree of certainty, I am doing some testing now regarding the root cause. I did find an issue in the logs regarding reading blocks from the disk errors, based on the posted logs. If I can integrate these 3 fixes into 1032, Id prefer we just go ahead and knock this out and have a mandatory in 4 hours. Rob |
|
|
|
when masternodes come out?
I believe Christmas 2017. As soon as things settle down we will head to the testnet thread on forum.biblepay.org, hopefully you can help test them. |
|
|
|
Somehow I got 1 040 000.00 Biblepay but now I can't syncronize?!
Please verify u r on 1031? |
|
|
|
My linux miners show up briefly once started but eventually disappear from the pool website. These are the last few logs: 2017-09-13 05:49:40 89UpdateTip: new best=13db8243c2bdc0778c90b4570eda7ec1469daf435fa5f9da10e7ae1d9513d84$
2017-09-13 05:49:40 ProcessNewBlock : ACCEPTED
2017-09-13 05:49:46 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we ar$
2017-09-13 05:50:45 connection from 175.204.123.147:51971 dropped (banned)
2017-09-13 05:51:34 DGW: Height 7392.000000, NewDiff 1b54a84f nActualTimespan 1134.000000 nTargetT$
2017-09-13 05:52:09 connection from 218.71.239.70:57766 dropped (banned)
2017-09-13 05:53:41 ERROR: CheckProofOfWork(): BibleHash does not meet POW level, prevheight 5478.000000 $
2017-09-13 05:53:41 ReadBlockFromDisk: Errors in block header at CBlockDiskPos(nFile=0, nPos=1999285)
** ProcessGetData:Cannot load block from disk.
2017-09-13 06:01:23 DGW: Height 7392.000000, NewDiff 1b54a84f nActualTimespan 1134.000000 nTargetT$
2017-09-13 06:02:47 connection from 218.71.239.70:57994 dropped (banned)
2017-09-13 06:05:26 connection from 77.106.146.145:54432 dropped (banned)
2017-09-13 06:05:31 89UpdateTip: new best=e45940fec237f88b0ee2a6f30d89d1875764f6a4ffe4180b52cbf03560ba874$
2017-09-13 06:05:31 ProcessNewBlock : ACCEPTED
2017-09-13 06:05:37 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we ar$
2017-09-13 06:09:47 connection from 175.204.123.147:52249 dropped (banned)
2017-09-13 06:12:34 89ERROR: CheckProofOfWork(): BibleHash does not meet POW level, prevheight 7392.00000$
2017-09-13 06:12:34 ReadBlockFromDisk: Errors in block header at CBlockDiskPos(nFile=0, nPos=3283261)Upda$
2017-09-13 06:12:34 ProcessNewBlock : ACCEPTED
2017-09-13 06:12:40 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we ar$
2017-09-13 06:13:15 ERROR: CheckProofOfWork(): BibleHash does not meet POW level with TxIndex Lookup, pre$
2017-09-13 06:13:15 ERROR: CheckBlockHeader(): proof of work failed
2017-09-13 06:13:15 Misbehaving: [2001:0:9d38:6abd:30d5:3e2e:5033:846c]:11527 (0 -> 50)
2017-09-13 06:13:15 ERROR: invalid header received 1f317d504e22a10b34d0a48334babd030c96265d5150b0129c9649$
2017-09-13 06:13:15 ProcessMessages(headers, 28677 bytes) FAILED peer=75
2017-09-13 06:13:44 ERROR:
CheckProofOfWork(): hash doesn't meet X11 POW Level, Prod 1.000000, Network main, PrevHeight 0
2017-09-13 06:13:44 ERROR: CheckBlockHeader(): proof of work failed
2017-09-13 06:13:44 Misbehaving: [2001:0:9d38:6abd:30d5:3e2e:5033:846c]:11527 (50 -> 100) BAN THRESHOLD E$
2017-09-13 06:13:44 ERROR: invalid header received 9002b29834f151df58cd77f3cccb1b34e35c2e1bd1110cffa237ab$
2017-09-13 06:13:44 ProcessMessages(headers, 82 bytes) FAILED peer=75
What version r u running? The strange thing about your log is the line with "x11 pow level" in it- that is off in f7000? |
|
|
|
Pool is having problem in last few hours, some of my miners dropped from pool. The message in miner did not show revert to solo mining, but somehow 1 of my machine manage to mine a block   I found inconsistent block rewards, usually it was nearly 20000 (199xx), but why sometimes I have 20000, and the last mined block get only 5832? About 30 minutes ago I was monkeying with the sessionstate and it knocked everyone off for about 15 mins, they are all back, lucking the block was solved 1 minute before they got booted. Anyway, unrelated to that, the low reward is happening now due to the diff > 300. See the prior forum page we were discussing that this morning. One miner pointed 100 servers at the pool today. Oh I see, so any problem with the diff value or this is normal due to large network hashrate now? (Sorry I have searched a few page back on this thread but did not find the discussion about this, just ignore me if it was answered) And wow, big miners are coming now, biblepay is getting popular I think its partially due to the algorithm change. I believe the algorithm change increased the diff from .05 to 100.00. The other part from 100-400 or so is probably the miner with 100 servers. I'll try to add a few more metrics to the pool that show total miner participation, total kh/s, and things like that. Then maybe Happy can jump in and formulate a change for the call to networkhashps. The code was already in GetBlockSubsidy to lower the subsidy when the diff rises, but it was never expected to rise from .01 to 500, I actually expected the subsidy to drop to about 17000 between now and Christmas. So we might have to adjust that slightly in the next mandatory. |
|
|
|
|
Show Posts
