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