BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)

[joelles]

mined 2 blocks in couple days with 8 core xeon 3.5ghz.

Pool isnt mining much for me.

[bible_pay]

Wow. What just happened? 50% of the leaderboard just disappeared....and most of my miners have gone..

Looks fine, very stable over 24 hrs.

[orbis]

Wow. What just happened? 50% of the leaderboard just disappeared....and most of my miners have gone..

Looks fine, very stable over 24 hrs.

Rob, at that time were almost all of my miners gone from pool too.
Pool load was more than 110%.
And since that moment (around) we didn't hit any block. Maybe it is coincidence, but...

[capulo]

yes, 40 blocks hole for now... something is wrong again

[tiras]

yes, 40 blocks hole for now... something is wrong again

no blocks hit since     2/3/2018 8:36:19 AM

[orbis]

I've wrote to Blockfolio, to add SouthXchange for BBP... they response very fast, but...

We do not currently support SouthXchange but want to get all exchanges added eventually. Thanks for letting us know of your interest in SouthXchange and Biblepay.

So, it seems, that we'll wait little bit longer.

[bible_pay]

yes, 40 blocks hole for now... something is wrong again

no blocks hit since     2/3/2018 8:36:19 AM

Hmmm, everything looks fine- pool is synced to the top, hasnt solved anything in 40 blocks, miners are solving work, dont see any huge number of errors... Looks like a rash of bad luck in the pool right now.

[tmc808]

Distributed Computing Update for Cancer Research:

The project has quite a few hurdles, and some are very high indeed, but I feel optimistic that we will have a working cancer research system in testnet within 30 days.

I've eliminated centralized and private cancer research systems from the equation, for security concerns.  The system that is most compatible for our altruistic ecosystem and from a security standpoint is Rosetta@Home.  

David Anderson has replied (creator of the open infrastructure network computer grid) and gave instructions to submit our paper for peer review in the Journal of Grid Computing, and is on-board to help.  I have not heard back from David Baker yet (Rosetta).

I'm working with Martin Grothe from Ruhr university on certifying the large issue that his crypto-security class discovered last year in distributed computing networks that affected one crypto.  His team reverse engineered a key function which has later been plugged.  Im sending him the algorithm and we will have the updated algorithm in testnet before going live with testing.

The non-technical version of the whitepaper is 70% complete.  The whitepaper is 10% complete.  We also need a user guide (0% complete).

However, where we have made significant progress is in the proof-of-concept for testnet.  

There are several very high hurdles, and several low hurdles.  The low hurdles include scalable research payments (IE superblocks), normalized daily researcher credit measurement files, disaster recovery modes, cosmetic provisioning, Sanctuary roles, etc.  The higher level hurdles include: Custom UI for researcher association, Researcher security, Sanctuary Quorum Voting protocol, Anti-DDOS DC Grid for Credit Providers, Voting in the daily researcher file, Research Burn transactions and burn security, etc.

70% of the low level hurdles are programmed.  50% of the high level hurdles have been programmed.  

Testnet Readiness Level:  65%.

Rob,

This is awesome progress in a very short amount of time. This is exactly the kind of spark that BBP needs! To that end, I have a friend who is in the medical device industry that could use the the cycles as well for cancer screening in oral/dental settings. Really cool stuff! In the future I can see cool things there
 
Also, pursuant to the pool stuff I can help with the pool project documentation and also helping on the systems administration side. Check your PM on Slack if you have a moment please. :-)

Thanks again for your hard work without which we wouldn't really be here!!

[SEO_Account]

With only 10% chance of solving a block it would not be uncommon to go on a 40 streak of no luck or even 50, 60, 70+ blocks with no luck. Have you ever played roulette? even with 50% chance to be red each time you will encounter 20+ streaks with no red. Which would be like hitting 100 streak with no blocks at 10% of the hashing. No one complains when we hit 3 in a row even though that is unfair to the solo miners! Long term it will even out to be what it is suppose to be. Sometimes we run hot sometimes we run cold it's just how it works.

[orbis]

For me it's ok, that we didn't hit any block for a longer time, but I wanted to point on that, there were something unusual happened at that time. Pool cpu load over 110% and missing miners is not something expected.

[rascolians]

For me it's ok, that we didn't hit any block for a longer time, but I wanted to point on that, there were something unusual happened at that time. Pool cpu load over 110% and missing miners is not something expected.

It was as though the pool 'broke wind'...one minute it seemed fine, the next, half of the leaderboard disappeared...I've no idea what it could have been but I was there and saw it...

[tmc808]

@virus what kind od xeons?

Dual X5650 (genproclimit=20)
Two E3-1270 (ech genproclimit=1)

But I use my own version of miner.
I have pulled changes to github https://github.com/biblepay/biblepay/pull/8

You can clone it from https://github.com/svirusxxx/biblepay

Donation can be send at BLz3cLnpLAg1roBZAqSwAFKsjtMYTVVsqn

I compared your modified kjv.cxx vs. the standard and have these results to show:

System is Gentoo Linux 4.9.76-gentoo-r1 DUAL CPU SMP Sat Jan 20 18:27:21 PST 2018 x86_64 Intel(R) Xeon(R) CPU E5620 @ 2.40GHz GenuineIntel GNU/Linux
32GB RAM

Code:

./biblepayd -daemon -maxconnections=250 -dbcache=4096

using modified build after merging kjv.cxx changes manually:

Code:

 ~/biblepay/src # ./biblepay-cli getmininginfo
{
  "blocks": 28714,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 2098.922736862373,
  "errors": "",
  "genproclimit": 16,
  "networkhashps": 101469956475.5698,
  "hashps": 4396.397605111778,
  "minerstarttime": "02-03-2018 23:23:52",
  "hashcounter": 262144,
  "pooledtx": 0,
  "testnet": false,
  "chain": "main",
  "biblepay-generate": true,
...
}

Using the standard source provides a slightly higher result working on the same block, 28714:

Code:

/usr/local/bin/biblepayd -daemon -maxconnections=250 -dbcache=4096  (installed version conforming to original source tree)

~/biblepay/src # /usr/local/bin/biblepay-cli getmininginfo
{
  "blocks": 28714,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 2098.922736862373,
  "errors": "",
  "genproclimit": 16,
  "networkhashps": 101469956475.5698,
  "hashps": 4474.51609599563,
  "minerstarttime": "02-03-2018 23:21:40",
  "hashcounter": 262144,
  "pooledtx": 0,
  "testnet": false,
  "chain": "main",
  "biblepay-generate": true,
...
}

I am curious to know what the scenario would need to be in order to see the enhancements you propose. Also, I tried to send you a PM regarding a donation but I could not because I am noobie Send me PM so we can discuss? Thanks!

[harrisvan87]

I dont know who del my post...! That was my though and wonder, i have no permission to say that ?? 0 coins last hours ? Really.. Not a fews it very frequently.. Maybe i not get much technical. But i hope not just reicieve  that was a bad luck for looking block of the pool.

[crypto2017guy]

what do these do and what values should i use to get the best mining performance i can?

gen=1
genproclimit=2

Thanks

[znffal]

what do these do and what values should i use to get the best mining performance i can?

gen=1
genproclimit=2

Thanks

gen=1
If this =1 then you will mine, if you set it =0 then your wallet won't mine. So leave as is.

genproclimit is what you can adjust to increase hps. Try increasing it slowly, see how your hps increases and monitor your CPU usage

[capulo]

40 blocks hole occasionally is ok, but if it goes with another and another hole and we solved 3 blocks in 15 hrs compared to 25 blocks in 24h before, then something is definitely wrong
we can use magic  1 step procedure from every helpdesk , restart it

[tmc808]

40 blocks hole occasionally is ok, but if it goes with another and another hole and we solved 3 blocks in 15 hrs compared to 25 blocks in 24h before, then something is definitely wrong
we can use magic  1 step procedure from every helpdesk , restart it

Completely agree. And I have feeling that somebody is using our hashpower.

The blocks are being processed, just not by the main pool.

Unfortunately the block explorer has been down for a while. Unsure of why.

[Alex873434]

40 blocks hole occasionally is ok, but if it goes with another and another hole and we solved 3 blocks in 15 hrs compared to 25 blocks in 24h before, then something is definitely wrong
we can use magic  1 step procedure from every helpdesk , restart it

Completely agree. And I have feeling that somebody is using our hashpower.

The blocks are being processed, just not by the main pool.

Unfortunately the block explorer has been down for a while. Unsure of why.

Which BX is down? I haven't recorded biblepay-explorer.org being down and it is up right now for me.

[orbis]

Yes, try https://biblepay-explorer.org it's working perfectly.

[tmc808]

Yes, try https://biblepay-explorer.org it's working perfectly.

Thanks!!

I was trying the block explorer within the Pool Menu, perhaps that link needs to be updated :-)