is there some ban / limitation for new ip addresses? i added some machines, but: after biblepayd starts, it takes ages until the blocks are loaded, measured traffic is below 80KB/s; when checking biblepay-cli getmininginfo, the blocks value is increasing very slowly. any similar problems? explanations? what to do? i use ubuntu 16. when i run speedtest-cli, the results are fast enough: download 42mbps, upload 11mbps. any thoughts?
Check machines time zone and time- we enforce network time - it wont sync until set. |
|
|
|
1.0.7.5 version seem have problem.
It is the second times occurred , I am re-indexing again.
I worry it will happen again....
Hello all!
I have been following this thread and this project for several weeks now and I am really excited to see the hard work and dedication going into developing all of this. However the last couple of days it seems to me that the only concern you have regarding troubleshooting is with the MN owners, not the miners.
Several people reported the above mentioned error and I also experience it regularly since updating to 1.0.7.5 on different machines, different networks, even different cities across Germany. So the error is definitely not on my side, because also the configurations on these machines differ from each other and each and every one gets this error after a few hours of mining.
However, no one has offered any permanent solution or even explained where this is coming from. I think the only reason so few people have this problem is because judging by the connected peers on my systems most people are still on the working version 1.0.7.1.
So when will this annoying problem be fixed? Another question you never answered was how this new "competitive mining" feature really works. Right now it seems to me that all the update did was giving an even bigger malus to the faster CPUs and DualCPU-systems and more and more degrading mining output. For example my 10 year old Core2 laptop with proclimit 1 is sometimes producing almost as many shares as my Dual-hexacore-Xeon server on proclimit 12, which is absolutely ridiculous.
I understand that your main priority right now are your precious masternodes, but please don't forget about us small-time miners and remember that without the miners your blockchain wouldn't really work either. Comparing the output from before Christmas or even from last week I'm currently at approx. 10%, which barely - if at all - covers my electricity bill.
Thanks for your time and effort and God bless this project!
Edit: For clarification: up to now it seems that the error only occurs with the linux client (Ubuntu 16.04 LTS in my case), the windows wallet doesn't seem to be affected.
Hi Dave, Its just not true that we only care about precious masternodes. Here is the way I view the priorities right now just so you know: I want to ensure we are ready for block 24600, so we can pay our orphans. Next, I want to maintain production support levels. That includes any critical errors with 1075. And finally, I place a very low priority level personally on any "hash speed discussions". So maybe thats the point of contention. We only have enough resources to talk about the prod support and the critical errors and not about peoples mining speed, unless its an inconsistency in the pool that affects everyone. Of course we have time to talk about how competetive mining works. But first: So, Im not aware of a critical bug in 1075, and have not received a log. Can someone please give us a log so we can see what stopped the node in 1075?? There is no way to even look at a problem without a log. Can we have a look after we hit the 24600 block at the pool? I can help investigating and testing etc, no problem. It feels weird that we only hit 20-25% with nearly 2800 miners and 2390627.92 hps. Are there really lots of people solo mining, could be but I find it hard to believe if we look at the numbers and interest here on the forum. I know, even though we have officially 202 blocks per day, Alex pointed out that we have historically Always had 150 due to the nature of the bible hash algorithm. So, technically, the main pool is getting 33%, but still, its been dropping lately, not increasing. The pool has a system where it constantly checks the last 11 blocks every block to ensure it didnt reorganize and not pay- so Im sure its not an accounting error. You can always do the 'exec subsidy height' to see the payees of each block. Alex also has the pool marked in the BX. |
|
|
|
I need to restart some of my miners once/twice per day (reindex fixes them)
The miners that are failing use HTTPS.
The few miners that are running using http seems to be not affected (I haven't needed to restart them, but they are also slower machines)
@Dave, are you using HTTPS or http?
Interesting, indeed I use HTTPS on all of my miners (seemed like the right thing to do...), so perhaps it's really related to that. As soon as one is crashing again I will return to HTTP and see if it runs stable again. On another note: since the security update on the pool page (required password change) I have to log on again and again because the auto-logoff is set to just a couple of minutes. This is really annoying when you want to watch your miners' output over let's say 1-2 hours because I have quite a complicated pw that I need to type over and over again.  Just as a suggestion: would it be possible to 1) change the auto-logoff time to maybe 1 hour or something like that and 2) add the function that after typing username and password you can just hit return to login (instead of having to click on "login"; not sure if this is complicated to realise...)? That shouldnt be happening, its a little more complicated on the back end; we post an HTTPS cookie into your machine with our domain and your sha256 hash of your cookie, and try to use it after the session expires - it has a dynamic expiry time due to have an app pool, so best thing is to 1) ensure your new pass actually works by logging off many and logging on, 2) open more than one window and see if you do not need to log in twice, 3) ensure you are accepting cookies from the pool. If all this works you should no longer have that log off nuisance. Looking at https issue now (in the core wallet).. it appears to be isolated to https traffic... |
|
|
|
Hi Dave,
Its just not true that we only care about precious masternodes.
Here is the way I view the priorities right now just so you know: I want to ensure we are ready for block 24600, so we can pay our orphans.
Next, I want to maintain production support levels. That includes any critical errors with 1075. And finally, I place a very low priority level personally on any "hash speed discussions". So maybe thats the point of contention. We only have enough resources to talk about the prod support and the critical errors and not about peoples mining speed, unless its an inconsistency in the pool that affects everyone.
Of course we have time to talk about how competetive mining works.
But first:
So, Im not aware of a critical bug in 1075, and have not received a log. Can someone please give us a log so we can see what stopped the node in 1075??
There is no way to even look at a problem without a log.
Thank you for your explanations (also in your other posts about the competitive mining. Indeed that makes sense. I have copied the last lines from the debug.log, where the error occurs (wasn't really sure where to start...): 2018-01-04 13:15:15 Resetting mining tithe 259.000000CMasternodePayments::FillBlockPayee -- Masternode payment 660063277955.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:15:28 CMasternodePayments::FillBlockPayee -- Masternode payment 660063277955.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:15:39 Resetting mining tithe 260.000000CMasternodePayments::FillBlockPayee -- Masternode payment 660063277955.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:15:52 CMasternodePayments::FillBlockPayee -- Masternode payment 660063277955.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:16:41 CMasternodePayments::FillBlockPayee -- Masternode payment 660063277955.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:17:37 Resetting mining tithe 261.000000CMasternodePayments::FillBlockPayee -- Masternode payment 660063277955.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:18:00 CMasternodePayments::FillBlockPayee -- Masternode payment 660063277955.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:18:18 Resetting mining tithe 262.000000CMasternodePayments::FillBlockPayee -- Masternode payment 660063277955.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:18:58 CMasternodePayments::FillBlockPayee -- Masternode payment 660063277955.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:19:48 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:19:48 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:19:51 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:19:56 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:20:08 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:20:12 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:20:27 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:20:32 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:20:37 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:20:57 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:21:17 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:21:45 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:22:16 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:22:23 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:22:36 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:22:38 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:22:47 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:22:47 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:23:46 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:24:42 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:25:08 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:25:09 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:25:11 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:26:05 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:26:33 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:26:52 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:27:34 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:28:10 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:28:36 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:29:06 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:29:25 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:29:36 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:30:16 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:30:24 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:30:44 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:31:37 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:32:10 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:32:29 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:32:50 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:33:55 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:34:22 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:34:37 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:34:53 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:35:09 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:35:49 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:36:16 ERROR: Write: Failed to open file /home/david/.biblepaycore/peers.dat.add3
2018-01-04 13:36:18 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:36:23 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:37:47 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:38:25 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:38:32 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:39:00 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:39:26 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:39:58 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:41:09 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:41:44 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:42:14 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:42:14 Unable to open file /home/david/.biblepaycore/blocks/blk00000.dat
2018-01-04 13:42:14 ERROR: WriteBlockToDisk: OpenBlockFile failed
2018-01-04 13:42:14 *** Failed to write block
2018-01-04 13:42:14 Error: Error: A fatal internal error occurred, see debug.log for details
2018-01-04 13:42:14 Unable to open file /home/david/.biblepaycore/blocks/blk00000.dat
2018-01-04 13:42:14 Unable to open file /home/david/.biblepaycore/blocks/rev00000.dat
2018-01-04 13:42:14 tor: Thread interrupt
2018-01-04 13:42:14 torcontrol thread exit
2018-01-04 13:42:14 opencon thread interrupt
2018-01-04 13:42:14 addcon thread interrupt
2018-01-04 13:42:14 mnbcon thread interrupt
2018-01-04 13:42:14 scheduler thread interrupt
2018-01-04 13:42:14 net thread interrupt
2018-01-04 13:42:16 ProcessNewBlock : ACCEPTED
2018-01-04 13:42:16 msghand thread interrupt
2018-01-04 13:42:16 PrepareShutdown: In progress...
2018-01-04 13:42:16 StopNode()
2018-01-04 13:42:16
BiblepayMiner -- terminated
2018-01-04 13:42:16 Verifying mncache.dat format...
2018-01-04 13:42:16 Loaded info from mncache.dat 6ms
2018-01-04 13:42:16 Masternodes: 84, peers who asked us for Masternode list: 0, peers we asked for Masternode list: 0, entries in Masternode list we asked for: 0, masternode index size: 84, nDsqCount: 2149
2018-01-04 13:42:16 Writting info to mncache.dat...
2018-01-04 13:42:16 Written info to mncache.dat 6ms
2018-01-04 13:42:16 Masternodes: 84, peers who asked us for Masternode list: 0, peers we asked for Masternode list: 0, entries in Masternode list we asked for: 0, masternode index size: 84, nDsqCount: 2856
2018-01-04 13:42:16 mncache.dat dump finished 12ms
2018-01-04 13:42:16 Verifying mnpayments.dat format...
2018-01-04 13:42:16 Loaded info from mnpayments.dat 135ms
2018-01-04 13:42:16 Votes: 24615, Blocks: 2564
2018-01-04 13:42:16 Writting info to mnpayments.dat...
2018-01-04 13:42:16 CMasternodePayments::FillBlockPayee -- Masternode payment 660063284675.000000 to BGW1hEmxB48ydQpmJk5cpPoMrdCxWocbBs
2018-01-04 13:42:16 Written info to mnpayments.dat 121ms
2018-01-04 13:42:16 Votes: 25214, Blocks: 2624
2018-01-04 13:42:16 mnpayments.dat dump finished 259ms
2018-01-04 13:42:16 Verifying governance.dat format...
2018-01-04 13:42:16 Loaded info from governance.dat 16ms
2018-01-04 13:42:16 Governance Objects: 22 (Proposals: 19, Triggers: 2, Watchdogs: 1/1, Other: 0; Seen: 24), Votes: 0
2018-01-04 13:42:16 Writting info to governance.dat...
2018-01-04 13:42:16 Written info to governance.dat 5ms
2018-01-04 13:42:16 Governance Objects: 22 (Proposals: 19, Triggers: 2, Watchdogs: 1/1, Other: 0; Seen: 26), Votes: 847
2018-01-04 13:42:16 governance.dat dump finished 21ms
2018-01-04 13:42:16 Verifying netfulfilled.dat format...
2018-01-04 13:42:16 Loaded info from netfulfilled.dat 0ms
2018-01-04 13:42:16 Nodes with fulfilled requests: 10
2018-01-04 13:42:16 Writting info to netfulfilled.dat...
2018-01-04 13:42:16 Written info to netfulfilled.dat 0ms
2018-01-04 13:42:16 Nodes with fulfilled requests: 9
2018-01-04 13:42:16 netfulfilled.dat dump finished 0ms
2018-01-04 13:42:16
BiblepayMiner -- terminated
2018-01-04 13:42:16 Shutdown: done
Hope this helps. 018-01-04 17:24:33 Unable to open file /root/.biblepaycore3/blocks/blk00000.dat
2018-01-04 17:24:33 ERROR: WriteBlockToDisk: OpenBlockFile failed
2018-01-04 17:24:33 *** Failed to write block
2018-01-04 17:24:33 Error: Error: A fatal internal error occurred, see debug.log for details
2018-01-04 17:24:33 ProcessNewBlock : ACCEPTED
2018-01-04 17:24:33 libevent: Error from accept() call: Too many open files
2018-01-04 17:24:33 libevent: Error from accept() call: Too many open files
2018-01-04 17:24:33 libevent: Error from accept() call: Too many open files
2018-01-04 17:24:33 scheduler thread interrupt
2018-01-04 17:24:33 opencon thread interrupt
2018-01-04 17:24:33 mnbcon thread interrupt
2018-01-04 17:24:33 msghand thread interrupt
2018-01-04 17:24:33 addcon thread interrupt
2018-01-04 17:24:33 net thread interrupt
2018-01-04 17:24:33 PrepareShutdown: In progress...
2018-01-04 17:24:33 StopNode()
2018-01-04 17:24:34 Verifying mncache.dat format...
2018-01-04 17:24:34 Loaded info from mncache.dat 0ms
2018-01-04 17:24:34 Masternodes: 0, peers who asked us for Masternode list: 0, peers we asked for Masternode list: 0, entries in Masternode list we asked for: 0, masternode index size: 0, nDsqCount: 0
2018-01-04 17:24:34 Writting info to mncache.dat...
2018-01-04 17:24:34 Written info to mncache.dat 4ms
2018-01-04 17:24:34 Masternodes: 84, peers who asked us for Masternode list: 0, peers we asked for Masternode list: 0, entries in Masternode list we asked for: 0, masternode index size: 84, nDsqCount: 23119
2018-01-04 17:24:34 mncache.dat dump finished 4ms
2018-01-04 17:24:34 Verifying mnpayments.dat format...
2018-01-04 17:24:34 Loaded info from mnpayments.dat 0ms
2018-01-04 17:24:34 Votes: 0, Blocks: 0
2018-01-04 17:24:34 Writting info to mnpayments.dat...
2018-01-04 17:24:34 Written info to mnpayments.dat 473ms
2018-01-04 17:24:34 Votes: 25442, Blocks: 2647
2018-01-04 17:24:34 mnpayments.dat dump finished 502ms
2018-01-04 17:24:34 Verifying governance.dat format...
2018-01-04 17:24:34 Loaded info from governance.dat 0ms
2018-01-04 17:24:34 Governance Objects: 0 (Proposals: 0, Triggers: 0, Watchdogs: 0/0, Other: 0; Seen: 0), Votes: 0
2018-01-04 17:24:34 Writting info to governance.dat...
2018-01-04 17:24:34 Written info to governance.dat 3ms
2018-01-04 17:24:34 Governance Objects: 19 (Proposals: 17, Triggers: 1, Watchdogs: 1/1, Other: 0; Seen: 84), Votes: 831
2018-01-04 17:24:34 governance.dat dump finished 3ms
2018-01-04 17:24:34 Verifying netfulfilled.dat format...
2018-01-04 17:24:34 Loaded info from netfulfilled.dat 0ms
2018-01-04 17:24:34 Nodes with fulfilled requests: 0
2018-01-04 17:24:34 Writting info to netfulfilled.dat...
2018-01-04 17:24:34 Written info to netfulfilled.dat 0ms
2018-01-04 17:24:34 Nodes with fulfilled requests: 9
2018-01-04 17:24:34 netfulfilled.dat dump finished 0ms
2018-01-04 17:24:35 Shutdown: done
I need to restart some of my miners once/twice per day (reindex fixes them) The miners that are failing use HTTPS. The few miners that are running using http seems to be not affected (I haven't needed to restart them, but they are also slower machines) @Dave, are you using HTTPS or http? Thanks a lot for the logs guys. Huge question, the machine that is running over HTTP successfully without restarting, is it running 1075 also? This way, I can isolate this down to the HTTPS feature. Thanks! |
|
|
|
so what these numbers means?
"hashcounter": 23921555,
"competetive_mining": true,
"competetivemining_hash_counter": 22418835,
"global_competetive_mining_tithe": 89,
"competetive_mining_ratio": 0,
"pooledtx": 0,
at least hashcounter vs competetivemining hash counter?
It means since started, you hashed 23.9MM hashes, but only 22.4MM were good, therefore competetive mining kicked in and tithed 89 satoshis (total over the period) to fill in the difference. Its a small effect, but could be big on a very fast processor. The more threads you run the smaller the effect. If you ran this on a fast processor with only 2 threads, the satoshis would increase quickly. The (competetive tithe amount) does reset to 0 after the block switches. (The global_competetive value does not, it just stays to show you something happened). EDIT: competetive_mining_ratio is the amount of edge you achieved running the competetive feature as a %, but since its smaller than .01% it appears as zero. |
|
|
|
I created a new dedicated forum for mining issues, more specifically for HashPs discussions, troubleshooting, General Mining, etc. Would someone like to volunteer to moderate this forum? You could moderate and help solve technical issues with hashps. And finally, Alex suggested an awesome idea, that we maintain a spreadsheet with a reference to OS, processor type and hashps. Whoever the mod is, could you please create a global sheet also? http://forum.biblepay.org/index.php?board=6.0
|
|
|
|
|
The competetive mining feature, 1075, and 1075 in general should not be lowering hash PS, as the entire algo is still the same, and the feature is a small enhancement to the miner.
What the feature does is starts adding a tithe, destined to the foundation, of 1 satoshi when you run out of mining nonces.
This usually only happens on fast processors.
Biblepay requires a low nonce to prevent us from being ported to an asic or gpu.
To give you an example of the current maximum nonce in the current block, type exec pinfo from the RPC.
The 'pinfo' output is the max nonce biblepay allows for the next block to be solved.
If your machine was so fast, say running 20 threads that its nonces were greater than the exec pinfo level, competetive mining would kick in and add a foundation tithe of 1,2,3,4++ satoshi (once every 30 seconds or so) to keep you hashing at full speed.
|
|
|
|
1.0.7.5 version seem have problem.
It is the second times occurred , I am re-indexing again.
I worry it will happen again....
Hello all!
I have been following this thread and this project for several weeks now and I am really excited to see the hard work and dedication going into developing all of this. However the last couple of days it seems to me that the only concern you have regarding troubleshooting is with the MN owners, not the miners.
Several people reported the above mentioned error and I also experience it regularly since updating to 1.0.7.5 on different machines, different networks, even different cities across Germany. So the error is definitely not on my side, because also the configurations on these machines differ from each other and each and every one gets this error after a few hours of mining.
However, no one has offered any permanent solution or even explained where this is coming from. I think the only reason so few people have this problem is because judging by the connected peers on my systems most people are still on the working version 1.0.7.1.
So when will this annoying problem be fixed? Another question you never answered was how this new "competitive mining" feature really works. Right now it seems to me that all the update did was giving an even bigger malus to the faster CPUs and DualCPU-systems and more and more degrading mining output. For example my 10 year old Core2 laptop with proclimit 1 is sometimes producing almost as many shares as my Dual-hexacore-Xeon server on proclimit 12, which is absolutely ridiculous.
I understand that your main priority right now are your precious masternodes, but please don't forget about us small-time miners and remember that without the miners your blockchain wouldn't really work either. Comparing the output from before Christmas or even from last week I'm currently at approx. 10%, which barely - if at all - covers my electricity bill.
Thanks for your time and effort and God bless this project!
Edit: For clarification: up to now it seems that the error only occurs with the linux client (Ubuntu 16.04 LTS in my case), the windows wallet doesn't seem to be affected.
Hi Dave, Its just not true that we only care about precious masternodes. Here is the way I view the priorities right now just so you know: I want to ensure we are ready for block 24600, so we can pay our orphans. Next, I want to maintain production support levels. That includes any critical errors with 1075. And finally, I place a very low priority level personally on any "hash speed discussions". So maybe thats the point of contention. We only have enough resources to talk about the prod support and the critical errors and not about peoples mining speed, unless its an inconsistency in the pool that affects everyone. Of course we have time to talk about how competetive mining works. But first: So, Im not aware of a critical bug in 1075, and have not received a log. Can someone please give us a log so we can see what stopped the node in 1075?? There is no way to even look at a problem without a log. |
|
|
|
I can't remember who requested the pop-up bible verse when a transaction is received by the wallet, but it will be in the next release.
Great idea! Thanks:  |
|
|
|
Hey Rob, Alex, et al
Thanks for all your hard work. I have a question for you.
When the auto withdrawals from the pool started, I was on vacation for Christmas and New Year's and I wasn't able to check in on my mining or my pool account. Now that I'm back I see that my pool account has been sending my mining yields to an address I don't recognize. I think it was post-password reset time and I'm trying to figure out where those went. It's about 10k BBP. Can I PM one of you the address to see if it's a dev address or find out where they went? Let me know if you can help and what I can do. Thanks again.
Edit: Actually, It looks like there was a transaction in my history of a little over 8k BBP to my mining account but those BBP are nowhere to be found. I'm a bit lost here.
Hi Durbellion, I see your account. You can see your transaction history in Reports | TransactionHistory | Click Printer icon to export to csv (we recently changed it to pull the full history since inception). Anyway auto-withdrawals will show up as "Auto Withdrawal" , but you actually dont have any yet. Primarily because your balance in the pool has to be higher than 100 bbp and the auto withdrawal has to exceed 10 bbp, so you have not been triggered yet. However I see you did click the button to authorize auto withdrawals to BKLZE, and that address has been withdrawing successfully. This brings up a good point for everyone: The pool will not be responsible for giving any credits back that have been sent to bad addresses. Once you click that auto-withdraw authorize button, if the pool sends a reward, its gone and cannot be reversed. We do check the validity of the address before sending, and we will trace a txid for you, but if it went to a wallet you do not control, those funds are gone forever and will not be credited back to your account. (In contrast to the pool hack, where I am working to ensure everyone receives their actual pool balance refunded to them, as that is Owed to them). Now, moving on, obviously we need a way to shut off auto-withdrawals, that button will be added today. So please download the CSV and email me if you have any concerns, everything looks OK. |
|
|
|
|
I can't remember who requested the pop-up bible verse when a transaction is received by the wallet, but it will be in the next release.
|
|
|
|
One thing I stumbled upon that should be fixed.
The password reset emails on the pool never expire.. if you click on a link from days ago that was sent to you it will reset the password again. Also, It should maybe email you the new password rather than displaying it immediately. But if the password reset email link expired say after 10 minutes.. then it's probably not a huge deal to display the password immediately.
just some thoughts..
thanks.
Fixed; now they only work once. |
|
|
|
Christians will like knowing this, but when Christians say "the Flood Myth is in every Culture", it isn't in every Culture, but it is in a lot of Cultures, and it was in Native American (Not just Native US Native Americans) Mythology. There is an Incan God called Viracocha and a Colombian God called Bochica. These were people who were said to have come and taught the Native Americans various different Crafts, and Stone Working, and other arts. It is most likely that this was a Person who came on a Boat. I believe the Legend says he came from the water on a Snake or a Feathered Snake, and then taught everyone, and then left by Walking away on the Water; he is also pictured with Tears to represent the Rain and Lightning Bolts in his Hands. This is likely a story about someone who came from Asia or Africa; maybe even a whole Tribe that just became part of America and a story was passed down. Thor Hyderdhal proved that you do not need a Hull on a Boat to get across the Ocean. https://en.wikipedia.org/wiki/Thor_HeyerdahlAnd also similarly to the Christian God, there is a Mountain God, called Apu (Lord), and the storm God called Huracan (Heart of the Sky) the source for the word Hurricane. Looking at these Gods gives you a better Perspective on the Mountain, Desert, Sea God of the Middle East. And they have a Flood Myth, and in their Flood Myth God created the Earth 3 times. Once, he created people from Stones, Giants, and they displeased him so he Flooded the Earth, then he made Humans and they displeased him, so he Flooded the Earth, and now we are in the 3rd phase supposedly after whatever the Native American name for Noah is. So the Flood Myth exists in very different Places, and the same Religion exists in very different iterations. Because really everything mentioned here is Jewish, except for Viracocha who is like their Jesus. And this is kind of strange, but Corn supposedly comes from America, but there are examples where Jewish people used Corn Motifs on their Spears. But supposedly they didn't know about Corn. This is what happens when you veer away from the Lord, Jesus Christ: http://www.dailymail.co.uk/femail/article-5228857/A-10-year-old-drag-queen-founded-drag-club-kids.htmlI've seen too many NDEs where Jesus gave an Indian or Muslim a second chance by showing him Hell, and it becomes clear these principalities exist where some of the "gods" you refer to are actually running a principality in hell. If you hang around these spirits long enough, you will eventually find they backstab you. The same ones you think Love you are going to turn on you some day, because they dont care about your soul. They want their daddy to get it so they will have an easier night with less torture for themselves. John Ramirez talks about this, hes done it all: https://www.youtube.com/watch?v=VEmE-cQEX3Y |
|
|
|
still dont want to believe that POOL with 2.3MHs got only Blocks Mined (24 hour period): 51 (25%) = this numbers is last 8 days and diff changed  something is wrong with pool´s setup biblepay: can you to change pool fees from 15% to back 2% its no need to get so much BBP for you Sure, send me 1 BTC cash, and Ill divide it over the accounts. 1BZHuKRNE47fzZgJhTj1JfhyA9MtqMGExr Let me know asap. |
|
|
|
Was working in slack on this last night, and we have come to the conclusion that some nodes still contain a remnant of the bad gobject. Note that the python error you receive will definitely go away when this object is deleted:
1996fe78ce9efd7a3b6deefbcd2e120b75f850909ad8f702062a517b1cb27ae1
So please gobject vote-many 1996fe78ce9efd7a3b6deefbcd2e120b75f850909ad8f702062a517b1cb27ae1 funding no, then delete yes, then delete *.dat files except wallet.dat then resync. I believe this object is now fleeced out of the supermajority, as I see 90% of the sanctuaries are now staying in ENABLED state again. We just need to clear it out of the minority now.
I did double check that its not on any of my seed nodes also on windows - its gone.
Superblock, block 24600 coming sometime Friday, Im excited!
I've tried everything to get rid of that now, with no luck.. It's just stuck there.. I get success doing the funding and delete opertions, but no matter what happens the MN list of objects always has that in.. I've tried deleting everything bar the .conf files and wallet.dat, on both the controller and sanctuary.. Letting them catch, up performing the fund/delete, with success, but always the object is still there.. Even if after the fund/delete i delete everything from the controller as above, and restart.. I'm out of ideas, and starting to hope that this will all just go away with block 24600.. Lets wait 24 hours, and try again. I think it might be the chosen peers on your node due to your geographical location. Im relatively confident it will dissapear soon, as I have been watching the watchdog expired masternode count decrease each hour. Tomorrow, just ban all your peers except node.biblepay.org and see what happens. |
|
|
|
expired getting rewards?  interesting didnt know that watchdog expired is in game ... thanks virus It takes 30 hours for a sanctuary to get evicted from the payment queue. |
|
|
|
One thing I stumbled upon that should be fixed.
The password reset emails on the pool never expire.. if you click on a link from days ago that was sent to you it will reset the password again. Also, It should maybe email you the new password rather than displaying it immediately. But if the password reset email link expired say after 10 minutes.. then it's probably not a huge deal to display the password immediately.
just some thoughts..
thanks.
Good idea, will jump on it, thanks a lot. |
|
|
|
./biblepay-cli gobject list all triggers
returns only 1 object for me : "4a1f347cd49a97d36f105b1908d33a3ed3cfb5d11485000d2908313f4c2d9490":
so I'm assuming my node if fine ATM , isn't it ?
Yes sir, your node is acting correctly. Your good on your end. EDIT: btw, the single and correct gobject for our budget is : 4a1f347cd49a97d36f105b1908d33a3ed3cfb5d11485000d2908313f4c2d9490 We are working on merging the appropriate commits for security and preventing this type of gobject failure in the future also. Im interviewing blockchain devs in my inbox, so hopefully we will have a dedicated security programmer soon. Regarding the pool, I got a message from Hong Kong mining saying they are going to push a lot of hash power soon against the pool, I told them hit us with whatever they have. Tiras, if it turns out the pool becomes overloaded and MinersofMen gives up we may need your help again. I will monitor the situation closely. We also received a request for a BiblePay interview in a magazine, I sent the magazine to Togo, good luck Togo. |
|
|
|
|
This months outgoing letters have been sent to the translators.
Note: One of my jobs is to spot check some of the outbound letters to ensure the quality is OK.
Unfortunately I found some letters that didn't meet the Letter Writing Tips guidelines and had to be deleted.
Some of the problems this month:
- Some asked the child to come and visit them in their home country. The child is helpless and penniless, so please don't do that.
- One misled the child and lied to them, basically promising them a bright future and asked to come join me at my house (in another country) but with no gift up front. If you aren't buying the child plane tickets and a goat up front, don't make empty promises or mislead them.
Suggestion:
- Not one outbound letter contained a picture. A picture of a pet, family member or memory could brighten one child's day. Consider adding a picture the next time you write a letter.
- Other issues:
- A couple users are copy/pasting the same content with no depth (IE too short, contains no feelings), just basically says Hi Sweetie you are cute, I hope you are blessed by us, Thanks. This is basically empty, and we are paying $14 for that letter? We need to put a good 20 minutes of effort into the letter and give it substance and feelings. Please, downvote these letters. I will be increasing the content requirements of the system.
- We need to limit the max letter writing ability down to 2-3 letters per month per person since the same few accounts seem to be abusing the system (writing without substance).
To view the letter writing tips - please read these tips and use guidelines for writing and for voting:
Log in to the pool, click: Orphans | Sponsored Orphan List | Write | Letter Writing Tips
|
|
|
|
|
Show Posts
