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

[harrisvan87]

Anyone have idea about get rid of dump bbp on SX ? That make our value of BBP was under control from an whale for buy in.

[capulo]

just put 10m buy order on 6

[MasternodeCap]

Hello there,

masternodecap.com has updated BiblePay (v1.2.0.1)!
Nodes monitoring and stats for $BBP.

You can especially be warned when :

• the status of a node changes
• your nodes get rewarded
• an upgrade of your wallet is available

Happy masternoding!

[bible_pay]

Licht, we need to verify multiwallets are not solving low nonces in parallel.

Still not sure how this would work. I will try to test on multiwallets this weeks, but I have still no idea how this could work. Shouldn't be a multiwallet miner even be slower because of the overhead of multiple instances running?

On windows 10 I get 2khps on i5 4c 3.2ghz. same hardware on Ubuntu 18 gives me 2.5khps

Different processor-software architectures yield different speeds because of the ability to perform AES encryption and native sha256 hashing.  Notice closely I said -software after the processor.

Anyway, this discussion is primarily about multiwallets, not hashing speed.

[bible_pay]

** POOL.BIBLEPAY.ORG hashing status update **

Rob did some testing on Sunday night with Capulo so far, and Rob believes the multiwallet "edge" against pools has to do with multiple slow threads solving similar work in the same 500ms range - work that would not help the pool solve an actual block.  This was found by auditing reports of solved fractional shares comparing the pool itself at large to the largest miners - IE select all work being solved sorted by solve time descending, and I found a high incidence of clumps of 2 threads solving a share within 500ms of another on the large miners, but not from the pool at large.

So at this point, pool.biblepay now marks work that is solved within 1 second of another share as Stale (the user still gets credit for the first solution, first in still wins).  This resulted in an approx 50% decrease in rewards to the top 5 pool users (IE anyone running multi-wallets).

At this point Capulo is auditing the running nodes, he might be setting up two environments for us one with multi-wallet one with no multi-wallet. 
Licht is also testing purepool to find how this affects his pool, as I'm sure there is a similar effect going on since we use the same hash algorithm and fractional share types.

So until I hear back from the testers, for now the small miners should see a boost in payments.

I also wanted to say, there is quite a bit of confusion, and miscommunication being spread.

Pool.biblepay does not pay users off of the HPS2 figure.  We pay off of the shares solved in the Leaderboard.  So if you solve 10 shares in the leaderboard and receive 100bbp, a person with 20 shares would be receiving 200bbp.  There is no strange calculation on the back end going back to HPS2 then back to PPH.  (You can see in block distribution its always been this way).  (Someone here had written a tool to try to exploit the pool based on HPS2 figures in error, and misled some of the miners).

[GaryH]

I've been doing GPU crypto mining for about 2 years now.  A new coin can drop and I can fire up many different OS's and various miners with mining algo's but one of the hardest things is BBP as it constantly changes.

When BBP didn't seem to work it was check for a new wallet, if that didn't work I dug through a lot of sites spending hours trying to get the proper configs.  Then PODC and setting that up and now I guess it's gone.  Anytime I get it figured out then a few months later it's a whole new thing.  Now it appears to be POG?

If we're to grow, things need to become easier which means older non-computer users from church would be able to download BBP and the system would configure itself and it could alert them a new wallet needs to be downloaded etc.  I think BBP scares a lot of users off with all the tech/configs and acronyms.

Honestly though, I can configure Awesome Miner, or HiveOS much easier for a coin--one time setup that could take 30 mins or less--load up a miner and configure for a pool and it just runs for weeks, months.  Wallets rarely change once mature.  All these changes back and forth with BBP isn't helping any--maybe it adds to the frustration which bleeds out into the forums.

I want to help the orphans (we have two kids through Compassion we support) through BBP--but we need to stabilize what is going on as a non-tech person won't waste their time with all the changes.  A one click wallet/miner sort of setup that grandma can use sort of thing.  Even if we can't get to a grandma setup, at least we stabilize the coin and it's methods. 

My opinion is we're gonna need to make it easier for users to come to BBP.

[secoccular]

If we're to grow, things need to become easier which means older non-computer users from church would be able to download BBP and the system would configure itself and it could alert them a new wallet needs to be downloaded etc.  I think BBP scares a lot of users off with all the tech/configs and acronyms.


My opinion is we're gonna need to make it easier for users to come to BBP.

Interesting, I was just having a conversation about this, and the conclusion was the same as yours. Crypto is hard enough to understand and mess without the constant change. It's easy to forget how people outside this crypto world don't have endless amounts of time and energy to research all these changes and troubleshoot. It's easy to forget how intimidating all the jargon sounds. Or maybe we want to show off our intelligence and pride to impress the non-technical folks, make them really work hard to stay current on this coin? BBP may require more work to set up and keep running with all its changes/upgrades. We should be honest that it just requires more effort, good or bad. And then we shouldn't blame Rob for constantly innovating, and we shouldn't blame the coin for not being more popular.


I recall Rob saying a while ago, that BBP is really geared towards tech-savy Christians. Rob, if I have that wrong, please chime in with what the target audience is as you see it. If it is really more for technical Christians who enjoy spending time on github and doing testing, then BBP is actually a complete success. That is, it's appealing to that small group it's intended for.

If it's designed for anyone interested in charity and Christian values, then I feel we may be missing a good bit of the core audience.  

[sunk818]

** POOL.BIBLEPAY.ORG hashing status update **

...

So at this point, pool.biblepay now marks work that is solved within 1 second of another share as Stale (the user still gets credit for the first solution, first in still wins).  This resulted in an approx 50% decrease in rewards to the top 5 pool users (IE anyone running multi-wallets).

.

Would setting different worker ids be enough to prevent "stable" submissions that are within 500ms of each other? Or do we need a separate logins for pool.biblepay.org? At least, it'll look like we have more users with unique IDs. As long as auto withdraw is working, it should be somewhat automated except the one time setup for each account.

My opinion is we're gonna need to make it easier for users to come to BBP.

..
I recall Rob saying a while ago, that BBP is really geared towards tech-savy Christians. Rob, if I have that wrong, please chime in with what the target audience is as you see it. If it is really more for technical Christians who enjoy spending time on github and doing testing, then BBP is actually a complete success. That is, it's appealing to that small group it's intended for.

This is a good opinion. At the very least, we need a "resync" option within the QT wallet where everything is erased except the essential files (masternode.conf, biblepay.conf, and wallet.dat). BiblePay had so many mandatory upgrades in the last few months, it was hard to keep up with. I've spent an inordinate amount of time and effort supporting others those that missed a mandatory update and had to start from scratch.

[bible_pay]

If we're to grow, things need to become easier which means older non-computer users from church would be able to download BBP and the system would configure itself and it could alert them a new wallet needs to be downloaded etc.  I think BBP scares a lot of users off with all the tech/configs and acronyms.


My opinion is we're gonna need to make it easier for users to come to BBP.

Interesting, I was just having a conversation about this, and the conclusion was the same as yours. Crypto is hard enough to understand and mess without the constant change. It's easy to forget how people outside this crypto world don't have endless amounts of time and energy to research all these changes and troubleshoot. It's easy to forget how intimidating all the jargon sounds. Or maybe we want to show off our intelligence and pride to impress the non-technical folks, make them really work hard to stay current on this coin? BBP may require more work to set up and keep running with all its changes/upgrades. We should be honest that it just requires more effort, good or bad. And then we shouldn't blame Rob for constantly innovating, and we shouldn't blame the coin for not being more popular.


I recall Rob saying a while ago, that BBP is really geared towards tech-savy Christians. Rob, if I have that wrong, please chime in with what the target audience is as you see it. If it is really more for technical Christians who enjoy spending time on github and doing testing, then BBP is actually a complete success. That is, it's appealing to that small group it's intended for.

If it's designed for anyone interested in charity and Christian values, then I feel we may be missing a good bit of the core audience.  

Well I believe this is exactly why all the change occurred over the last few months.  We adopted PODC as our holy grail originally (when we believed it would root out the rich botnets), and then I typed a whole page of information in the OP post of the POG voting thread as to why I believed we were too complicated for the average user, and then we voted to move to POG because of this, so we could implement a no-configuration system miner, and mine with zero setup (IE turnkey mining).

We almost succeeded in that next release, and then we had a bug in production in POG that caused me to temporarily move us to pure POBH.

My opinion has not changed, I still think PODC is too complicated of an animal to run as the single algorithm, and I think we are a light year ahead once we release the ability to mine through campaigns *or* through POBH.  (As either one can be automated in our setup wizard).

I'm very close to creating a document with a grid in it (similar to a roadmap, but different in the sense that it will be comparison based) and this should paint a picture of where I think we were, we are, and where we are going and Ill be sure to include ease of use on this grid so we can see if there has been an improvement in this area.

There are dimensions and dynamics involved in every decision.  I am going to explain why I think we are a light year ahead in our new position in testnet.

[bible_pay]

I've been doing GPU crypto mining for about 2 years now.  A new coin can drop and I can fire up many different OS's and various miners with mining algo's but one of the hardest things is BBP as it constantly changes.

When BBP didn't seem to work it was check for a new wallet, if that didn't work I dug through a lot of sites spending hours trying to get the proper configs.  Then PODC and setting that up and now I guess it's gone.  Anytime I get it figured out then a few months later it's a whole new thing.  Now it appears to be POG?

If we're to grow, things need to become easier which means older non-computer users from church would be able to download BBP and the system would configure itself and it could alert them a new wallet needs to be downloaded etc.  I think BBP scares a lot of users off with all the tech/configs and acronyms.

Honestly though, I can configure Awesome Miner, or HiveOS much easier for a coin--one time setup that could take 30 mins or less--load up a miner and configure for a pool and it just runs for weeks, months.  Wallets rarely change once mature.  All these changes back and forth with BBP isn't helping any--maybe it adds to the frustration which bleeds out into the forums.

I want to help the orphans (we have two kids through Compassion we support) through BBP--but we need to stabilize what is going on as a non-tech person won't waste their time with all the changes.  A one click wallet/miner sort of setup that grandma can use sort of thing.  Even if we can't get to a grandma setup, at least we stabilize the coin and it's methods. 

My opinion is we're gonna need to make it easier for users to come to BBP.

Let me save you 1200 pages of research:

If you want to mine Biblepay-classic now in prod, just add the line:
gen=1

To your config file and start the wallet. 

So in prod, we are not hard to set up. (Or you can pool mine by adding the pool= settings).


Regarding our future, see this thread for where we are with Evo:
https://forum.biblepay.org/index.php?topic=391.new#new

Regarding an easy-to-start guide for Evo, it has not been written yet, but we will try to put something together for newbies before its released (most likely by the end of June).

[noxpost]

Exciting to see what the summer brings for us, especially as interest in crypto (in general) tends to go up as the reference value (Bitcoin) increases. If that continues together with our new rebase and new features, it could be a great back half of the year for BBP. I'd love to see new users from a different user base / population segment, and to widen our impact on the world!

[Lichtsucher]

So, I run my test against purepool, but I couldn't verify what happened on the main pool.
Maybe my tests are wrong, but in my tests, a single wallet gets around 25% more shares than a multiwallet setup. Looks like the overhead kills hit here.

My test system: I created an VM with ubuntu 18.04 and biblepay from the official repo. I created a new wallet and run it for 1 hour against purepool with 16 threads on my cpu (with 16 cores).
After that, I created 8 new wallets (each from scratch) and pointed them to a new biblepay adress in purepool, each with two threads. The cpu usage was the same with both setups.
I even gave the multiwallet setup two minutes more time, as they needed more time to fully start.

I tried it with more wallets (16), but my internet connection died trying it. Not sure why, I suspect my internet box died with the many open connections.
Maybe it wasn't enough wallets, but I can't test with more until the end of the week with more wallets.

Was my setup wrong?

[capulo]

forgot about #cores, just set 1 wallet, 40 threads and 8 wallets, 40 threads each...

i had best results with 20 threads/core and #wallets=#cores(also HT included)

[togoshigekata]

I saw a post earlier about the reddit mining guides being incorrect on the ANN post?

Mining Guides:
- Windows ------ reddit.com/r/BiblePay/comments/6umlqq/how_to_mine_biblepay_on_windows/
- Linux ---------  reddit.com/r/BiblePay/comments/6ummuj/how_to_mine_biblepay_on_linux/
- Raspberry PI -- reddit.com/r/BiblePay/comments/7qnbp4/bbp_miner_on_pi/

Pools:
- pool.biblepay.org (POBH)
- purepool.org (POBH)

==

BiblePay Mining History

July 23rd 2017:
- POW (Proof of Work) [Heat Mining] at launch {called POBH (Proof of BibleHash)}

February 2018:
- PODC (Proof of Distributed Computing) [Cancer Research Mining] added

February 2019:
- POG (Proof of Giving) [Daily Tithing/Donation Mining?] added
- PODC got voted on by masternodes for removal

March 15 2019:
- POG removed
- PODC removed

Note: it all reverted back to just POW while Rob works on updating to Dash Evolution,
after which I believe POG will be added back in

==

I previously updated the reddit mining guides, the reddit sidebar,
the Bitcointalk ANN post and the website to reflect that we are just Proof of Work right now

- 20.0% Monthly Budget
---- 10.0% Charity
----  5.0% IT (Software Development)
----  2.5% PR (Public Relations)
----  2.5% P2P (Letter Writing, Preach/Priest)
- 40.0% Proof of BibleHash Mining (POBH)
- 40.0% Masternodes (Sanctuaries)

==

Please correct me if Im wrong on any of this

[Lichtsucher]

forgot about #cores, just set 1 wallet, 40 threads and 8 wallets, 40 threads each...

i had best results with 20 threads/core and #wallets=#cores(also HT included)

You calc 1 wallet/40 threads  =40 threads  vs.   8 wallets/40 threads = 320 threads?
If that is right, what happens if you calc 1 wallet/320 threads?

[capulo]

yeah thats right
pool has limit 40 threads... so you cant use 320, but i'm not sure if also purepool has limit

[sunk818]

yeah thats right
pool has limit 40 threads... so you cant use 320, but i'm not sure if also purepool has limit

How do you set more threads with one core?

[bible_pay]

yeah thats right
pool has limit 40 threads... so you cant use 320, but i'm not sure if also purepool has limit

How do you set more threads with one core?

setgenerate true 40
Runs 40 mining threads regardless of cpu core count.

[bible_pay]

So, I run my test against purepool, but I couldn't verify what happened on the main pool.
Maybe my tests are wrong, but in my tests, a single wallet gets around 25% more shares than a multiwallet setup. Looks like the overhead kills hit here.

My test system: I created an VM with ubuntu 18.04 and biblepay from the official repo. I created a new wallet and run it for 1 hour against purepool with 16 threads on my cpu (with 16 cores).
After that, I created 8 new wallets (each from scratch) and pointed them to a new biblepay adress in purepool, each with two threads. The cpu usage was the same with both setups.
I even gave the multiwallet setup two minutes more time, as they needed more time to fully start.

I tried it with more wallets (16), but my internet connection died trying it. Not sure why, I suspect my internet box died with the many open connections.
Maybe it wasn't enough wallets, but I can't test with more until the end of the week with more wallets.

Was my setup wrong?

Before I answer I just want to double check, how hard is each share (IE how many minutes does it take to solve one share on an avg pc), and does purepool check the nonce as each small share is solved?  The reason I ask is pool.biblepay rejects nonces higher than the allowed nonce for the share.

[bible_pay]

Exciting to see what the summer brings for us, especially as interest in crypto (in general) tends to go up as the reference value (Bitcoin) increases. If that continues together with our new rebase and new features, it could be a great back half of the year for BBP. I'd love to see new users from a different user base / population segment, and to widen our impact on the world!

Let's rally for the Orphans in 2019!