Re: BiblePay - New Coin Launch

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.