Quote from: dave_bbp on March 17, 2019, 07:51:28 AM

Quote from: bible_pay on March 16, 2019, 08:55:58 PM

Quote from: togoshigekata on March 16, 2019, 08:45:17 PM

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

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)