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

[capulo]

from pool:
one limit is 40k and then when you click confrim in email:

This withdrawal amount exceeds BiblePay's hot wallet limit; please withdraw less than 1001 bbp.

and last:
Sorry, a user has recently withdrawn a large sum of BBP. Please wait 120 seconds and try again.

large=1000

increase limits, i dont want to do 120 withdrawals in 2 min intervals

Ill look at this a little later today, but the key is setting up your auto-withdrawals so you get paid automatically once per morning @ 9am.

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?

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

[bible_pay]

hash1 is not affected in solo or pool mining, sum of wallets hash power is +- still same

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

i mean hash1 in pool or hps in solo (i think it is same number) is not affected by multiwallets
if you run 2 wallets, it just split to ~half and so

only hash2 in pool is affected by multiwallets

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

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

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!

[bible_pay]

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.

[seeksilence1]

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

[bible_pay]

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

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

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

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.

[bible_pay]

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.

[bible_pay]

Im not sure if the information in this link is still true, but inblue tested it back in September 2017
http://wiki.biblepay.org/Multiple_Instances
Id rather everyone know about it, than just a few

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

[bible_pay]

from pool:
one limit is 40k and then when you click confrim in email:

This withdrawal amount exceeds BiblePay's hot wallet limit; please withdraw less than 1001 bbp.

and last:
Sorry, a user has recently withdrawn a large sum of BBP. Please wait 120 seconds and try again.

large=1000

increase limits, i dont want to do 120 withdrawals in 2 min intervals

Ill look at this a little later today, but the key is setting up your auto-withdrawals so you get paid automatically once per morning @ 9am.

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?

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

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

[bible_pay]

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

[bible_pay]

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.

[secoccular]

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.

[noxpost]

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

[dave_bbp]

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.

[sunk818]

looooooooooooooooooooool

ROB tempting tempting tempting

good drugs, hallucinations, delusions, good good bbp, there you go...

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

[fearfighter]

how long til sx is back?

[bible_pay]

looooooooooooooooooooool

ROB tempting tempting tempting

good drugs, hallucinations, delusions, good good bbp, there you go...

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

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!

[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?

[togoshigekata]

PolisPay important announcement
"it has come to our knowledge through the means of our PolisPay Card Provider and our lawyers,
that our provider was having a set of problems with Mastercard.
As we have been told, Mastercard never gave them permission to sell cards outside of Mexico
...
the implications of this result in us being unable of selling cards outside the country, at least for now,
as Mastercard has blocked our provider from validating transactions from cards with a registered living address in other countries."
https://medium.com/@PolisBlockchain/polispay-important-announcement-7f639965ca43

[bible_pay]

PolisPay important announcement
"it has come to our knowledge through the means of our PolisPay Card Provider and our lawyers,
that our provider was having a set of problems with Mastercard.
As we have been told, Mastercard never gave them permission to sell cards outside of Mexico
...
the implications of this result in us being unable of selling cards outside the country, at least for now,
as Mastercard has blocked our provider from validating transactions from cards with a registered living address in other countries."
https://medium.com/@PolisBlockchain/polispay-important-announcement-7f639965ca43

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.