Topic: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes) - page 185. (Read 243386 times)

how long til sx is back?

Does 10M sound better as GPU miner bounty posted on github and provable to work with PoBH solo and pool mining?

To be honest, I'm still confused as to how pool.biblepay pays or calculates its "shares".
Here's what I've tested over the last 2 hours (both servers with dual L5640):
Server A: 1 wallet, nproclimit=40 (maximum)
Server B: 12 wallets, nproclimit=8 each (so "96" in total)

Server A: HPS: 6050, HPS2: 450-480k, shares: approx. 90-100
Server B: HPS: 510-560 each (sum: 6350) , HPS2: between 50 and 70k (sum: approx. 700k), shares: between 9 and 14 (sum: approx. 130)

So either the single instance takes much longer to get to its maximum (but it hasn't changed over the last 30 minutes), or there's still a slight advantage for running multiple wallets on large machines ...
However, this is all for nothing, if the pool looks at "HPS" for payout/block distribution, which I don't know if it does.

I have a difficult time even fathoming why such a post would be made. Just to make people angry? I'm not here to see stuff like that - banned or not, that's not appropriate for this community.

Edit: post in reference has been deleted. Thanks mods

I'm sure this will be an unpopular opinion, but since we are apparently getting rid of PODC, it might be a good time to take another look at the rewards distribution. I'm thinking that we take some of the podc rewards, and double the charity amount to 20%. Crazy, I know, but follow me here:

BBP prides itself as only contributing to charities that are 75% efficient (75% of funds pass through to those in need). But as a charity, look at us. We are 10% efficient. I've had people ask me before, "wouldn't it just be better to donate to Compassion, where 75% of funds reach orphans, instead of 10% through BBP?" If anyone knows how I should reply to this type of question. I'm all ears.

Now I know BBP isn't just strictly a charity, so it's not reasonable to have 75% efficiency here. At the same time, how much patting ourselves on the back should we have, when 4 times the rewards that go to orphans go back into our pockets as masternodes? (I admit my bias against masternodes).

I don't know the answers, but my heart says it should at least be brought forward. If we're no longer contributing to boinc crushing, we should find a way to use those rewards in a beneficial way. As always, just my opinion.

Now that pool.biblepay.org has been adjusted to be harder to mine per share, I would appreciate it if a volunteer will test the total Shares Rewarded in one hour in a multi-wallet environment vs a non multi wallet environment.

C-CEX is open.  They opened on their own after seeing our mandatory.

Pool.biblepay.org just increased its daily payout to 50% of the users balance. 

I updated this wiki document to explain the situation and that there is No exploit as of 2019.

MULTIWALLET EXPLANATION


So way back in September of 2017, we degraded the proof-of-bible-hash algorithm by attempting to compensate full mining nodes with More bbp - the goal was to reward the single full node with more bbp for mining as compared to a botnet (we suspected one existed in Japan with 300 copies of biblepay), and the goal was not to penalize rich users with many computers, but instead, at the time it was more about ensuring that if someone Transplanted the algorithm out of biblepay and into a GPU, it would require so much overhead (in speaking to the full node through IO per hash) it would be more wasteful than running the original biblepay-core software miner.

We accomplished this by making the miner do more full-node work (IE work related to the lookup of the information in the txindex) and this sounded novel at first, ensuring more rewards to those running a full node.

However the unintended consequence was people started running multiple copies of biblepay per machine, and this ended giving the multi-wallet an advatage total hashpersecond higher than simply running one copy. 

In response to this inblue measured it and when we found out about it towards the end of 2017, we modified POBH to do more hashing in c (we added a custom c hashing algorithm called biblepay.c) and this consumed additional clock cycles by 50% more per individual bible-hash (still keeping KJV bible lookups and anti-gpu code), meaning we removed the multi-wallet exploit back at Christmas 2017 when we went to F7000 and Sanctuaries.

So now, have no fear, all CPU mining is roughly equal.  All we have to do is ensure no one figures a way to port us to GPU, and that the pools are consistent!

Thank you for supporting BiblePay.

Ok, great news!

POBH is certified to not give a miner any multi-wallet advantage!

From my tests, I took a Ryzen Windows PC and loaded 5 copies of biblepay.  
Results:
1 biblepay instance running, minersleep=0, 98% cpu utilization, solo mining, 25 threads : 5900 hps
5 biblepay instances running, minersleep=0, 100% cpu utilization, solo mining, 20 threads per instance: 1200 hps each: 6000 hps total for the machine
NOTE: The 100 hps discrepency is because the 1 instance didnt do as much context switching as the 5 (NORMAL).
No edge found!

Ill edit the wiki page with this new found info.
I challenge ANYONE that thinks they can run POBH in a GPU, Or bleed any edge out of BiblePay using MultiWallets to publically post here and show us!  Its not possible to cheat our other users!  Ill also pay 1 mil bbp reward to anyone who can prove that they did it publically, with provable environment checked in to github after testing (GPU or Multiwallet).

Ill explain separately why we had a multiwallet conversation in v2 of POBH back in Sept 2017.

Regarding the pools, to ensure there is no exploit for multiwallets, I took the first step of lengthening the POW requirement for every share, so now you will solve less shares per hour but the results should still be the same.  I want a FAIR ENVIRONMENT for everyone in the pool and out of the pool.  Id appreciate it if Dave and Capulo can help us certify the environment by doing some side testing against the pool- just make sure the small miiner and the big miner are equal.  Id like to do more work on this phase also before closing this issue.

Regarding the 10% withdraw limit per day I will look into this today.

Pure POBH is the temporary plan until BiblePay-Evolution is released.

We should have all the info on Evo in about 5 days - I will be creating a wiki document explaining the whole thing at the same time we go into testnet with Evo (in 5 days).

What's the plan after PODC retired? Will we stick in POBH or POG after bug fix?

Daemonko, stop posting here you are banned.  BitcoinTalk admins, ban him.
If you have anything constructive to say email it to [email protected] and he will pass it on to the community as someone with integrity that is not banned.

In the mean time, I will certify POBH publically and then ask volunteers to help replicate.
Then we will certify the pools.

Just to clarify your post to everyone else:  HPS2 was not a TRICK.  HPS2 was just a reading that we passed on to the user of their total clients HPS gathered from the sum of their wallets transmissions to Us.  We always paid off of HPS in the pool.

So to re-state what Ive said all along:

Pool.biblepay used to have two columns:  Your HPS (for share assessment) and your HPS2 (that matched the clients total HPS).  It was useful to see if your miners matched the pool thats all it was.  No tricks, nor has there ever been tricks!

I challenge any Theymos's, any naysayers, anyone who ever points the finger of .01 BBP of corruption on BiblePay or ME, that you will be rebuked and proven wrong in Jesus Name!

Long live Biblepay, and its integrity!

seems taht it works, but it did only maybe 10% from available amount

In this case Purepool should not be affected, as it only counts the valid shares of the users. No HPS2 tricks or anythink like that

Thanks, I havent looked at it yet but will be looking at this stuff today and PMs etc.

Android mobile app updated
(may take a few hours to propagate to all Google Play servers around the world)

i'm trying to set autowithdraw, i put address as default withdraw address ans click enable - looks good and saved, but if i checked it in other browser, then default address is empty and auto withdraws in ON
is it ok? or will it withdraw to empty address?