Just take a look at the BibleHash algo and how much estimated memory it would take to load the KJV array in the GPU executing environment (this is from kjv.cpp), and tell is if you believe its technically possible to duplicate the chained bible hash calls, the AES512 call, the hash call and the concatenated result call in a GPU.  And how secure or not secure you feel that someone will figure it out knowing what you know about c libraries and GPU code programming.

Im not too worried about ASIC, I heard they have such limited memory that loading the bible in it would be preposterous also you need a specific designed chip with the bible that would cost a lot of R&D for the first batch.

Edit: btw guys when you execute one biblehash, it uses 33,000 verses of the bible in a certain hashed order (depending on each hash its different).  IE its memory intensive since the entire bible is memorized.

TheSnat,  can you execute the AES512 encryption algorithm in your GPU miner and can you load the full KJV bible into its memory and duplicate the chaincalls?

What if I up the reward to 3 MM bbp?

To answer your question Dave, pool.biblepay pays the reward based off the Shares solved count (not the HPS) -- as that info is all it can assess for each miner privately.  Up til today, all the shares were equally hard.  So with the info you provided (that multiwallets mining against the pool have a 30% edge), I took a look at the solve data and it appears Possibly what might be happening is since the larger servers all ask for work at approx the same time, they might have an advantage in getting lucky and solving more than one very similar share (since the pool shares are much easier than an actual block).  Another words, lets say you run 20 threads, and thread 15 and 16 on a large server both satisfy the round requirements, and you end up with 2 shares solved in parallel where the small miner only gets 1.  This sounds fair, but the point is only one of those 2 really helps the group (as they were both equally hard but only one is valuable).

So what I did to address this is now we are shaking the bag up and now we hand out various random types of work to every thread, and this should technically result in threads not clashing and solving similar type work. 

When you get a chance can you please re-assess the situation in the pool again and see if A & B are more equal now.

Its a very sad day for Polis and Crypto payments (again).  When I saw their price drop 50% this morning I went to their thread on bitcointalk and the last post shows this sad info:
https://bitcointalk.org/index.php?topic=2627897.1080

Maybe they will work it out somehow by going with another bank.

Btw, I noticed cryptopia.nz is working out their problems and are back in read only mode.

Thanks Dave!  So whats nice about this scenario (and I assume your servers A & B are the same specs based on the HPS given above), is you have also given us backing that our "solo mining mode" (multiwallet vs non-multi-wallet in solo mode) yields the same HPS (6050 vs 6350 in your case).  So that is very, very good as it agrees with my figures I posted earlier.

Anyhew, let me take a look at the total shares of the pool next, and get back to you.  Im determined that we should be paying equal to Server B vs Server A so this is fair for everyone.  I had no idea people were launching servers with horizontal copies of BBP to exploit the pool(s).  They probably have been exploiting PurePool with this also...

Ill get back to you on the payout mechanism also, thanks for starting this test.

Oh, one more question if you know the answer:  Did this 95 share payout vs 130 share payout Decrease as of today and was it worse before (IE yesterday), IE did it improve today after I increased the complexity of each share?

Yes, if you are contributing 9M of it, it sounds waaaay better!

But anyway Im willing to put up 1M of my personal funds to start with.  If you want to fundraise the rest, thats not a bad idea.

The main point is there is a reward now, so if someone wants to hack us go for the reward, hackers!

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).

Daemonko, stop posting here you are banned.  BitcoinTalk admins, ban him.
If you have anything constructive to say email it to Nathaniel@biblepay.org 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!

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

So is anyone working on the side project to measure the Solo mining HPS in our POBH algorithm?

I don't see any replies.

This is our #1 priority.

Next, Licht and I need to get together and tweak the pools to ensure multiwallets dont have an edge.  But please take care of #1 first.

Please explain in more detail; I thought you told Dave there was a 500% edge?

Edit: I only know of one thing, HPS (not hash1 or hash2 anymore, I think we got rid of that a year ago).

We have to remove that edge from both pools within 7 days Lict, if it exists .

Anyway guys lets focus on solo mining first please tell us if the 2017 edge is water under the bridge?

I'll be available to help revamp the pool after church or tomorrow depending on what happens today.

Thanks Dave on the pool test, I wonder if Purepool is exactly the same.
IMHO, I really would not like to see an advantage at all (above 2%) for people running multi-wallets against a pool.  I don't believe it was intentional to give any 'poor users' a pool advantage, it was some type of effort we were making when we were discouraging bot-net activity.

But the elephant in the room right now is not the pool, its the base hashing algorithm.  We need to prove that there is no advantage to running more than one copy of biblepay in Virtual machines in solo mining first (the pool can be addressed later).

So if anyone will volunteer, please, set up a few copies of biblepay in solo mining mode and total the HPS for us and compare it to one instance at 100% compared to N instances at 100%.


Regarding the comments about HPS2:  Afaik, that figure has been removed from the pools.  That was just an estimate where we tried to match the pool throughput to the client total HPS but was not used for payment.