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

[bible_pay]

Hi,
Is the letter writing still working? I mean after all the changes, can we still do that?
Thanks

Yes, we need letter writers, only 10 written out of 80.  Reward is above 8K BBP.

[1715694818]

1715694818

[bible_pay]

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

No - incorrect - this was posted in September 2017, back when we had V2 of POBH.  Thats before we released Sanctuaries.


Thats why we have to prove this is no longer an exploit for miners since V3 of POBH (we are up to V14 now).

[bible_pay]

We introduce you the 1st and truly distributed Charity System in the world.
It enables anyone, no matter where you are, to send a donation that will be automatically
distributed among the people who need it ❤️ No middle man required. 100% transparency

Tweet: https://twitter.com/dash_text/status/1106573212962488322
Youtube: https://www.youtube.com/watch?v=lxrm9IFvZ0g

Dash Text is claiming they are the first truly distributed charity system,
I replied back talking about BiblePay
https://twitter.com/BiblePay/status/1106998813879881728

I dont believe they've shown any accountability like we have
https://dashtext.io/charityprogram/

Please like our tweet reply and spread the word of BiblePay!

(Wikipedia says Venezuela is 88% Christian: https://en.wikipedia.org/wiki/Religion_in_Venezuela)

If you dont have a Twitter account, sign up! its easy and free: https://twitter.com/signup

Im happy that they created a small feature (as compared to some of the other valuable features they have in the arsenal) to address 'distributing currency equally' to a group in a decentralized chain, but lets put this one in perspective.  Its one thing to develop Rain V2 (thats a way to mass crypto pay the group) as compared to being a truly decentralized autonomous charity.

The one thing that stops us from being a full fledged DAC is not having a sub-market for 'orphan shares' - sort of like the thing the housing market did with the collaterlized debt obligations (slicing them up into shares and selling them in the sub-markets), and I think we should take a look at that in our GSM in 20 days as I feal its technically feasible over the long term.  If we could pull that off we could truly be a 100% decentralized DAC, that would be impressive. 

[bible_pay]

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

I never saw this document, and I think what I want to do now is have someone test this publically here, and tell me if there really is any multiwallet exploit Now, and let us fix our hash algo if there is before we reopen the exchanges.

I want progress halted until I know the truth, and will not re-open on the exchanges until we work through this together!

There should be NO EXPLOITS IN OUR PRODUCTION ENVIRONMENT FOR USERS WHO ATTEMPT TO STEAL COINS THROUGH SYSTEM CONFIGURATIONS!

I wouldn't consider this an exploit,   seems more like it's helping the algorithm to work more efficiently?

The overall gains are marginal.

Thanks, but unfortunately his wiki shows the results to be 50% or more edge for people that run BiblePay of 10 instances of 10 VMs inside one computer, vs the One computer simply running on all threads, so I don't feel we can discount it as marginal without proving it completely wrong.

I do agree with you, if someone had a 1% edge after installing 5 copies of biblepay on a machine, it wouldnt be worth checking.

So I need help, I do want to prioritize checking this, and give a professional opinion of what caused it in 2017, but first I want to prove its completely mitigated.  Ill fire a couple up today and do some tests, but I really want help from someone with a more powerful machine to test it and also this gives cross-reference to the issue.

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

[dave_bbp]

you are not right, difference is much much more than 10-15%, at least 500%, just not adjusting config, run more times same as single. so forgot about # cpu, put nproclimit 20+ everywhere

but this is not bug, it is pool feature to 'help poor miners' boosting their hash power arificialy (hash2)

Ah, now I see what you mean. So the actual "exploit" is not running multiple wallets, but increasing nproclimit far beyond your CPU core number. This is what tricks the pool into thinking that these are all small CPUs and pushes their HPS2.
The multiple wallets are only needed if you have a lot of CPU cores on one machine , because the nproclimit is capped at 40something.

I did some testing on pool.biblepay and this is definitely a thing. The same machines create much more "shares" and a higher "HPS2" (with HPS staying the same) by just increasing nproclimit to 16 or 24 (on 2 core systems).

That being said I think this should be either made clear for all users, or prohibited in some way, because you basically steal payout shares from people with a "conservative" setting ...

[bible_pay]

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

I never saw this document, and I think what I want to do now is have someone test this publically here, and tell me if there really is any multiwallet exploit Now, and let us fix our hash algo if there is before we reopen the exchanges.

I want progress halted until I know the truth, and will not re-open on the exchanges until we work through this together!

There should be NO EXPLOITS IN OUR PRODUCTION ENVIRONMENT FOR USERS WHO ATTEMPT TO STEAL COINS THROUGH SYSTEM CONFIGURATIONS!

I did a short (quick and dirty) test yesterday on the main pool with 2 identical machines (dual L5640 each). Machine A with 1 wallet (nproclimit=24) and machine B with 12 wallets (nproclimit=2). It came down to this:
A: wallet-hps: approx. 5000-5500; pool: 100-120 shares, HPS2 120-150k
B: wallet-hps: approx. 500 each; pool: 8-12 shares each, HPS2 7-14k each.

It's not easy to say, because the pool is wildly fluctuating in its hashrate display, but I think the advantage of running multiple wallets was (at least in this case) maybe 10-15 %. Not sure if this can be considered an "exploit".

Maybe I will test the same on purepool, but as I recall we tested this back in 2017 and on purepool there was no difference/advantage whatsoever ...


P.S.: one of my wallets sometime during the night crashed with the following ouput:

Code:

biblepayd: /usr/include/boost/thread/pthread/recursive_mutex.hpp:113: void boost::recursive_mutex::lock(): Assertion `!pthread_mutex_lock(&m)' failed.

The debug.log only showed this (but from a different timestamp than the crash):

Code:

 terminate called after throwing an instance of 'std::length_error'
  what():  basic_string::_M_create
2019-03-17 00:54:22 CGovernanceManager::UpdateCachesAndClean -- erase obj eda7079b949f1b75d4095d67ce6e30a3ad5f477892abe4017fcb079553f84b07
2019-03-17 00:54:22 CGovernanceManager::UpdateCachesAndClean -- erase obj cab433f02578c62fa70bf82c7e38a601b9d7f28ef4afaf4f0ded8606c7a3b5ac

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.

[bible_pay]

you are not right, difference is much much more than 10-15%, at least 500%, just not adjusting config, run more times same as single. so forgot about # cpu, put nproclimit 20+ everywhere

but this is not bug, it is pool feature to 'help poor miners' boosting their hash power arificialy (hash2)

Ah, now I see what you mean. So the actual "exploit" is not running multiple wallets, but increasing nproclimit far beyond your CPU core number. This is what tricks the pool into thinking that these are all small CPUs and pushes their HPS2.
The multiple wallets are only needed if you have a lot of CPU cores on one machine , because the nproclimit is capped at 40something.

I did some testing on pool.biblepay and this is definitely a thing. The same machines create much more "shares" and a higher "HPS2" (with HPS staying the same) by just increasing nproclimit to 16 or 24 (on 2 core systems).

That being said I think this should be either made clear for all users, or prohibited in some way, because you basically steal payout shares from people with a "conservative" setting ...

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.

[capulo]

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

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

[togoshigekata]

Yeah sorry I misspoke, it was September 2017, not 2018,
I cant believe how much time has passed!, We are only a few months from 2 year anniversary?

=

Just to clarify some things,
- PODC (Proof of Distributed Computing) was phased out / removed?
- What is the current block reward breakdown?

=

I can help edit our Reddit sidebar and Reddit guides

I can make an updated copy of the ANN post
(and update our other English ANN pages, I dont control most of the other translations though)
https://www.reddit.com/r/BiblePay/comments/7qmt6m/bitcointalk_main_post_language_translations/

Thesnat updated the Twitter profile
I updated my bitcointalk profile signature

Would need to also update the website and links, I saw main page was updated

Wiki would need economics page updated

We could probably wait on the white paper?

[sunk818]

Yeah sorry I misspoke, it was September 2017, not 2018,
I cant believe how much time has passed!, We are only a few months from 2 year anniversary?

=

Just to clarify some things,
- PODC (Proof of Distributed Computing) was phased out / removed?
- What is the current block reward breakdown?

=

I can help edit our Reddit sidebar and Reddit guides

I can make an updated copy of the ANN post
(and update our other English ANN pages, I dont control most of the other translations though)
https://www.reddit.com/r/BiblePay/comments/7qmt6m/bitcointalk_main_post_language_translations/

Thesnat updated the Twitter profile
I updated my bitcointalk profile signature

Would need to also update the website and links, I saw main page was updated

Wiki would need economics page updated

We could probably wait on the white paper?

Podc is gone but I think pog is making a come back...

So economics data will change breakdown with pog entering the mix.

Podc passages could be removed but there's value in keeping it for SEO reasons.

Maybe explain why podc is no longer supported and encourage pog. You can use the past text as a way to market to boincers, CPU miners, etc

[Lichtsucher]

is purepool still down and in solo mining mode?

Everybody should mine normal in pool mode on purepool right now. I did a hotfix for the podc/cpid problem yesterday.
I see normal mining on my own systems, too. Plus I see regular outgoing transactions.

Edit: But biblepay-central.org was way out of date. I disabled it for now.

[eyedoctrader1]

Hello fellow miners.  I need some help getting my wallet to go into syncing mode.  After the past week with all the changes to the wallet I discovered that I could not get my wallet to connect to the network.  I heard about adding "minersleep=0" to biblepay.conf file which I added.  I also increased my genproclimit up to the number of cores of my Xeon processor (4).  I upgraded to wallet version 1.2.0.1.  When I run the wallet it opens up showing it's behind by 9 days and then just sits there and says no block source available for hours.  It never connects to the network to perform the final syncing.  Also, I cannot run my masternode either while my wallet is in this non-operational state.  Can anyone tell me what changes I need to make to either biblepay.conf file or deletions to files in the biblepaycore directory that will reinstate the syncing process?

Here's a copy of my current biblepay.conf file:

addnode=node.biblepay.org
addnode=biblepay.inspect.network
#tithe=1
gen=1
genproclimit=4
minersleep=0
poolport=80
pool=https://pool.biblepay.org
workerid=eyedoctrader7_3

Thanks in advance to anyone who can help me get back online!

If you are already on 1.2.0.1 wallets then it should be pretty simple to get you back on track.
Close your wallets and first of all remove the "poolport" line from the config, since this is wrong for connecting via https.

Then on Linux do the following:

Code:

cd ~/.biblepaycore
rm -rf banlist.dat blocks/ chainstate/ database/ *.log fee_estimates.dat governance.dat mncache.dat mnpayments.dat netfulfilled.dat SAN/ peers.dat .lock .cookie

(On Windows simply paste "%appdata%/biblepaycore" in the explorer and delete everything in there except for "backups", "wallet.dat" and both configs (bbp and mn).

Then restart the wallet and let it sync from scratch. As I've written yesterday, this should be pretty fast right now. Check if you are on the correct chain with

Code:

getblockhash 107525
c6622f1ea9417e463925207ff578f1f697ee1209651e3890b23e2d45dfdd7bb7

Good luck!

Dave, thanks for your help.  I was finally able to get back online with those tweaks.  It did, however, take almost 15 minutes for the program to connect to the blockchain and to start syncing.  Initially I thought it was still broken.  I found that setting the genproclimit to my number of cores (4) only consumed roughly 50% of my CPU usage so I upped the number to 7 and now it is remaining consistently around 90 to 95%.  Is this the correct way to run the wallet and to make the setting?  Thanks for your help again!

[bible_pay]

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.

[capulo]

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

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

[MIP]

1.2.0.1 - BiblePay - Mandatory Upgrade

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

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

[Lichtsucher]

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