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

[bible_pay]

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!
[...]

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.

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.

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?

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.

[1715454853]

1715454853

[1715454853]

1715454853

[1715454853]

1715454853

[secoccular]

My money is on thesnat21 to be able to make a GPU miner for BBP. He solved the riddle of the BLE headers and made a GPU for that.

[bible_pay]

My money is on thesnat21 to be able to make a GPU miner for BBP. He solved the riddle of the BLE headers and made a GPU for that.

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?

[thesnat21]

My money is on thesnat21 to be able to make a GPU miner for BBP. He solved the riddle of the BLE headers and made a GPU for that.

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?

oy, I was not going to worry about it ...  lol i smell a conspiracy

[bible_pay]

My money is on thesnat21 to be able to make a GPU miner for BBP. He solved the riddle of the BLE headers and made a GPU for that.

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?

oy, I was not going to worry about it ...  lol i smell a conspiracy

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.

[thesnat21]

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.

I think it's possible, look at the memory requirement for cryptonight or ethereum,  it may have a performance hit due to the extra pieces.

ASIC's are possible, but not anywhere near cost effective (half a million R&D?)

[bible_pay]

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.

I think it's possible, look at the memory requirement for cryptonight or ethereum,  it may have a performance hit due to the extra pieces.

ASIC's are possible, but not anywhere near cost effective (half a million R&D?)

Ok, I have one reason I believe its not possible, let me e-mail you that reason and then please post if you believe it is not advantageous/feasible to port biblepay to GPU.

[bible_pay]

how long til sx is back?

Ill contact them and see if they would like to reopen in the next 48 hours.

[thesnat21]

I think it's possible, look at the memory requirement for cryptonight or ethereum,  it may have a performance hit due to the extra pieces.

ASIC's are possible, but not anywhere near cost effective (half a million R&D?)

Ok, I have one reason I believe its not possible, let me e-mail you that reason and then please post if you believe it is not advantageous/feasible to port biblepay to GPU.

Ok based on that I would concede gpu performance would be stifled a great deal..   I'll admit you thought quite a bit when putting this together.

[togoshigekata]

I updated the website, reddit and ANN post:

Reddit:  https://www.reddit.com/r/BiblePay/
Website:  http://biblepay.org/
ANN:  https://pastebin.com/raw/NVYwJ72b

Let me know if anything is incorrect or missing

(Note: Rob you will have to apply the new ANN if you like it,
its based on latest copy of yours with some slight modifications)

=

I also reached out to Masternodes.Online, they are having issue updating their daemon / syncing their chain, I gave them update/clean instructions

[secoccular]

Togo I think that last link isn't quite right.

[Sakic]

Southxchange is back

[bible_pay]

I updated the website, reddit and ANN post:

Reddit:  https://www.reddit.com/r/BiblePay/
Website:  http://biblepay.org/
ANN:  https://pastebin.com/raw/NVYwJ72b

Let me know if anything is incorrect or missing

(Note: Rob you will have to apply the new ANN if you like it,
its based on latest copy of yours with some slight modifications)

=

I also reached out to Masternodes.Online, they are having issue updating their daemon / syncing their chain, I gave them update/clean instructions

Updated.  Looks Good.

Thanks a lot Togo for your work, its always appreciated!

[noxpost]

Economics in the reddit sidebar are still PODC-based. We should probably align to the new ANN post.

[togoshigekata]

Economics in the reddit sidebar are still PODC-based. We should probably align to the new ANN post.

Hmmm, I noticed on my mobile phone the old version was cached,
on PC you can click ctrl + shift + R to do a hard reload of the page,
let me know if that works

[bbptoshi]

My money is on thesnat21 to be able to make a GPU miner for BBP. He solved the riddle of the BLE headers and made a GPU for that.

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?

oy, I was not going to worry about it ...  lol i smell a conspiracy

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.

ah, so "memorizing prayers" while the wallet is loading means that the whole bible is being stored into RAM?

[noxpost]

Economics in the reddit sidebar are still PODC-based. We should probably align to the new ANN post.

Hmmm, I noticed on my mobile phone the old version was cached,
on PC you can click ctrl + shift + R to do a hard reload of the page,
let me know if that works

Right you are. How embarrassing for me.

[thesnat21]

ah, so "memorizing prayers" while the wallet is loading means that the whole bible is being stored into RAM?

Memorizing prayers is scanning messages for Prayers and formerly PODC/POG, and loading items into lists that need to be processed.

This has nothing to do with the bible verses, that is part of the hashing routine

[bbptoshi]

ah, so "memorizing prayers" while the wallet is loading means that the whole bible is being stored into RAM?

Memorizing prayers is scanning messages for Prayers and formerly PODC/POG, and loading items into lists that need to be processed.

This has nothing to do with the bible verses, that is part of the hashing routine

OK, thanks.  I'm guessing the bible is stored in RAM for quick access while hashing?

I see here it takes up about 4mb (https://www.reddit.com/r/theydidthemath/comments/5icdvq/request_how_big_would_a_txt_file_of_the_bible_be/).

[thesnat21]

OK, thanks.  I'm guessing the bible is stored in RAM for quick access while hashing?

I see here it takes up about 4mb (https://www.reddit.com/r/theydidthemath/comments/5icdvq/request_how_big_would_a_txt_file_of_the_bible_be/).

Yes, like any other program you run