Hello everyone. I've been busy for a couple of weeks (actually still am ...) and just returned yesterday to find that everything changed again.  So far I managed to port my VPSs to Evo, resync, and mine with them on the main pool (which still seems to periodically wipe the whole leaderboard/all miners). I also successfully created a new sanctuary from my 3 old ones and received the first payments. BTW: I have used quite a lot of blockchains and can honestly say that BBP is (even without having to have addnodes) the fastest one to completely sync a node from scratch. Good job everyone!  Now I have some issues with my Windows 10 QT wallet. First of all it crashes from time to time (strange enough only at times where I'm not sitting in front of my PC ...) without any useful information in the debug.log Secondly I wanted to start joining the POG, but when I type "exec cpk [nick]" it only gives "Results": false,
"Error": "Unable to sign CPK BM2e5zvdEf8jcosQdhP6e7NRs8kEMqJy7U (Private key not available)" Wallet-Version Win64 QT 1.4.3.2 Any ideas? biblepay.conf: shrinkdebug=1
gen=1
genproclimit=8
minersleep=2
pool=https://pool.biblepay.org
workerid=dave_pc |
|
|
|
|
What's going on here? After the fork pools don't even have 10 % of the global hash rate. Is this an ASIC coin now?
|
|
|
|
i found non linearity in pool.biblepay.org i added dual 2680v2 to my account and wonder how low hps2 it gets, so i did some investigation and found this: 10 computers on one account - dual 2680v2 had 2 days average about 19k hps2, maximum was 30k i put another same hw on new account and it did avg about 40k and max about 49k then i started turning off computers on first account and hps2 for dual 2680v2 was almost instantly above 2 days max (>30k), and with every computer turned off it goes higher and higher when it stayed alone in account i got same results as in second account 40k avg, 49k max so not only multiwallets helps, but also multi accounts ps: it has nothing to do with pool performance or my internet or what, i used independent computers from different countries and when one account goes well, second had low hps2 I think you should test those large machines on purepool. It seems to have no weird calculations whatsoever but simply counts shares according to a CPUs capabilities.  |
|
|
|
|
Is this coin dead already?
If it's a mineable masternode coin with infinite supply, how do you expect this to ever go above 1 sats in price? This is the most inflationary concept one could imagine ...
|
|
|
|
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. |
|
|
|
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 ... |
|
|
|
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
|
|
|
|
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 http s. Then on Linux do the following: 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 getblockhash 107525
c6622f1ea9417e463925207ff578f1f697ee1209651e3890b23e2d45dfdd7bb7
Good luck! |
|
|
|
I installed (completely from scratch) the biblepayd PPA package on some of my small servers that formely did WCG and I gotta say I'm very impressed by the performance of the 1.2.0.1 network right now. A complete sync without any addnodes etc. (empty biblepay.conf) never took more than 20-30 minutes! Nice work so far! Also the main pool performed quite nicely over the last 24 hours. Just right now it seems to have a bit of bad luck with no blocks in more than an hour. Regarding the multi-wallet thing daemonko keeps posting: I tested it and I'm not sure it has a huge effect right now. It seems to be more or less the same. However the POBh algo still seems to give some bonus to small CPUs, so that my ARMs still perform quite well considering their comparably low absolute hash power. btw: for anyone needing chain confirmation: this is where all my machines are on right now (this chain has 98% 1201 clients): biblepay-cli getblockhash 107422
f3b23042cd4cac1a2224499c8a294445e37e292ec2d6414b72815cceaa5c907b P.S.: In the windows GUI wallet the bezaleel theme still has the POG in the menu bar. Would be useful to remove this in the newer releases, since it seems to crash the wallet. ;-) (Don't know about the other themes, since I never use them). |
|
|
|
Im seeing this hash on 90% of my peers:
getblockhash 107086
3dba45d9162957eb7feaf6e40e8fb9f55d6155236ab1dfbc4a5ab80bcb3bf0cc
POW diff: 1279
Its a little too early to tell; resyncing the pool; Ill check again in 20 mins.
This is also where my wallets (1199g synced from scratch) landed on. Let's hope the network can agree on this chain. Also the pool seems to accept the solutions now. Good work so far! |
|
|
|
Tried resyncing version 1199 on windows and linux, but all wallets are stuck at 107029 (hash f230b225783f479af743f4dc0fadb732cc633c18030617cfee270356129242fd). Then after a while my windows wallet restarts itself with the following log: ERROR: Found invalid chain with higher work (ChainState database corruption likely)
2019-03-14 06:56:00 ERROR: ConnectTip(): ConnectBlock b004cf0af87f1074542b0491123370ac179d2e4f2e4cb25be92a5e9c078aa207 failed
2019-03-14 06:56:00 InvalidChainFound: invalid block=aff336d0359664970b0e1c1599f3fd513904ad19a70d1e351c35ff91761aae6c height=107020 log2_work=59.188157 date=2019-03-14 01:04:00
2019-03-14 06:56:00 InvalidChainFound: current best=b58132e1ce51df1fe192c860f404bdf200fd66cf53d1929c7a25588eb7977240 height=107029 log2_work=59.188159 date=2019-03-14 02:04:46
2019-03-14 06:56:00 CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2019-03-14 06:56:00
ERROR: Found invalid chain with higher work (ChainState database corruption likely)
2019-03-14 06:56:00 CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2019-03-14 06:56:00
ERROR: Found invalid chain with higher work (ChainState database corruption likely)
2019-03-14 06:56:00 ProcessNewBlock : ACCEPTED
2019-03-14 06:56:00
** Erasing Chain and Rebooting Wallet Now ** Linux wallets just crash like this: Written info to mncache.dat 26ms
2019-03-14 07:12:16 Masternodes: 529, peers who asked us for Masternode list: 0, peers we asked for Masternode list: 7, entries in Masternode list we asked for: 22, masternode index size: 529, nDsqCount: 0
2019-03-14 07:12:16 mncache.dat dump finished 30ms
2019-03-14 07:12:16 Verifying mnpayments.dat format...
2019-03-14 07:12:16 ERROR: Read: Failed to open file /home/david/.biblepaycore/mnpayments.dat
2019-03-14 07:12:16 Missing file mnpayments.dat, will try to recreate
2019-03-14 07:12:16 Writting info to mnpayments.dat...
2019-03-14 07:12:16
BiblepayMiner -- terminated
2019-03-14 07:12:17 Written info to mnpayments.dat 338ms
2019-03-14 07:12:17 Votes: 49991, Blocks: 4964
2019-03-14 07:12:17 mnpayments.dat dump finished 372ms
2019-03-14 07:12:17 Verifying governance.dat format...
2019-03-14 07:12:17 ERROR: Read: Failed to open file /home/david/.biblepaycore/governance.dat
2019-03-14 07:12:17 Missing file governance.dat, will try to recreate
2019-03-14 07:12:17 Writting info to governance.dat...
2019-03-14 07:12:17 Written info to governance.dat 147ms
2019-03-14 07:12:17 Governance Objects: 410 (Proposals: 104, Triggers: 305, Watchdogs: 1/1, Other: 0; Seen: 412), Votes: 7961
2019-03-14 07:12:17 governance.dat dump finished 162ms
2019-03-14 07:12:17 Verifying netfulfilled.dat format...
2019-03-14 07:12:17 ERROR: Read: Failed to open file /home/david/.biblepaycore/netfulfilled.dat
2019-03-14 07:12:17 Missing file netfulfilled.dat, will try to recreate
2019-03-14 07:12:17 Writting info to netfulfilled.dat...
2019-03-14 07:12:17 Written info to netfulfilled.dat 1ms
2019-03-14 07:12:17 Nodes with fulfilled requests: 14
2019-03-14 07:12:17 netfulfilled.dat dump finished 1ms
2019-03-14 07:12:17 dumped database files ... I give up for now and will come back tomorrow to see if everything is running again ... |
|
|
|
Who is <NICKNAME>PoG @('_')@ Monkey</NICKNAME>?
Same address has used also StopCrashingBiblePay nick. I remember seeing this at least yesterday. Thanks. So far we have found a corrupted scriptPubKey on the PoG Monkey record. All exchanges are disabled. From what I can see preliminarily, the bad POG record is causing the core client to go into a condition where it ends up corrupting the reply messages to other nodes exacerbating the problem for people who are trying to resync. Let me continue to do more testing. Most likely we will need a mandatory upgrade release with a safer/more stable environment while we wait for Evolution. We may have to disable POG and move to POBH temporarily, we're checking. Waiting to see the outcome of this.. If you have to drop POG temporarily, how does this affect the PODC vote? The PODC retirement vote is winning by 100, so we only have 80 more blocks before it would be retired anyway. Nothing changes... as far as that goes. The governance module should come back up and we will see if any changes are occuring to that vote over the next 10 days (IE governance does not go away). The only thing that changes is blocks pay 50-50 to POW - Sanctuary (IE 5000 to POW/5000 to Sanc after governance escrow %) for a while, until Evolution. Wait, WHAT? Sorry, but this is ridiculous. May I remind you that the proposal was not just simply "retire PODC?" but actually "retire PODC in favour of POG?"! So by all that is right, if you now make the (rushed) decision to simply bury POG for good, then this whole proposal/vote has no more legitimacy whatsoever! So what you're saying now is, we not only give up on POG (which more and more seems to have been in beta stage at best), but also simultaneously bury the ONE system that has worked for more than a year now? And we're going back to our good old trusty botnet-mining? I hate to say it, but I'm afraid as soon as any exchange is gonna open up our trading again (that is if there is still an exchange patiently enough ...) this coin will dump hard.  |
|
|
|
|
Yep, same problem here. All wallets (Windows GUI and Linux) crashed or not responding. Tried starting from a clean core folder, but it crashed again after resyncing. The pool also seems to be down.
Strangely enough purepool apparently is still running (maybe because it's on an older wallet?).
|
|
|
|
dave Working for me now also...thanks
sunk818 pool looks ok, im getting rewards No problem. I think the pool.biblepay.org is definitely on a fork. I just updated my miners and checked with getblockhash to be on the "right" chain. Now I am at 99.99 % error percentage on the pool. Before (with some of them on the fork chain) I was at approx. 50%. |
|
|
|
I getting error : "PODCUpdate": "Unable to locate coins not marked as POG bankroll denominations."
Anyone have a suggestion on a fix for this.I have done several bankroll commands for POG & seemed to have effected my podc stakebalance. I can't get a PODC update to send for 3 days. Seems to be happening since wallet upgrade to 1198, but may just be a coincidence?
Someone mentioned a possible fix with a UTXO entry in biblepay.conf, but not sure what value to use. My totalrac is:
"Command": "totalrac",
"Total RAC": 21249.21,
"UTXO Target": 467482.6200000001,
"StakeBalance": 1732501,
"Threshhold to receive 10% rewards (below this UTXO Amount rewards are lost)": 16999.37,
"Stake Level Required For 10% Level": 17424.35,
"Stake Level Required For 20% Level": 42498.42,
"Stake Level Required For 30% Level": 84996.84,
"Stake Level Required For 40% Level": 127495.26,
"Stake Level Required For 50% Level": 169993.68,
"Stake Level Required For 60% Level": 212492.1,
"Stake Level Required For 70% Level": 254990.52,
"Stake Level Required For 80% Level": 297488.94,
"Stake Level Required For 90% Level": 339987.36,
"Stake Level Required For 100% Level": 382485.78,
"Total Team RAC": 5942801
I had this problem too. I fixed it by creating a "receiving address" named PODC (or something similar) and sending the amount of coins I wanted to use for PODC updates to this address (I chose mostly small inputs in coin control for that, but it doesn't really matter). Then add the following line to your config: utxooverride=XXXXXXXXXX with XXXXXXXXX being the amount of BBP you want to stake for PODC. In your case 400000 should be enough. After restarting it sent PODCupdates again and it does so until now (wallet 1198). P.S.: I just realized that the POG leaderboard in bezaleel theme is a bit buggy. First of all it doesn't "switch" the navigation bar highlight when activated (the bar always stays on the former), and also the leaderboard itself highlights a random person instead of myself. Even when I actively highlight myself it changes upon refresh. Nothing to worry about, only cosmetics. |
|
|
|
Please try forcing a podcupdate 'exec podcupdate true' then check your rac.
This is existing behavior - this is that if you miss a podcupdate (yours looks missing for 24 hrs) it queries 0 rac from wcg until you send a new podcupdate.
Yes I know, but the last output I posted is actually the answer for the forced PODC update (tried that several times): 21:42:21

exec podcupdate true
21:42:21

{
"Command": "podcupdate",
"PODCUpdate": "Processed (1) over 0 CPID(s) successfully."
}
Please try 'exec associate user pass true' then wait til the 5 confirms hits, then try again, and please, let us know that its fixed. I finally managed to do the reassociation (after my wallet completely crashing and messing up the blockchain data on a former attempt). I didn't have time to wait for the confirmation, but when I came back home I now I saw that my wallet had sent a PODCupdate and everything seems to be back in order right now. For the naysayers, Yes, I want to try this. This is because cpids' over 6 months old expire in the chain. We need non-expired DCC associations in the chain with valid wallet sigs.
This is just a coincidence of the timing, but the new wallet requires all of the elements to be present (IE I dont think its a bug).
I honestly have no idea what you even mean by that ... |
|
|
|
Please try forcing a podcupdate 'exec podcupdate true' then check your rac.
This is existing behavior - this is that if you miss a podcupdate (yours looks missing for 24 hrs) it queries 0 rac from wcg until you send a new podcupdate.
Yes I know, but the last output I posted is actually the answer for the forced PODC update (tried that several times): 21:42:21

exec podcupdate true
21:42:21

{
"Command": "podcupdate",
"PODCUpdate": "Processed (1) over 0 CPID(s) successfully."
}
this exatly happened to me today. I had to reasociate wallet with CPID again. Same. My rac is 10 now. I'm going back to earlier build Myself. I upgraded to make pogbuffer work but not at expense of podc payment. I tried that too, but older versions only give "invalid destination address". So I guess it's reassociation and additional wating time again ... |
|
|
|
Please try forcing a podcupdate 'exec podcupdate true' then check your rac.
This is existing behavior - this is that if you miss a podcupdate (yours looks missing for 24 hrs) it queries 0 rac from wcg until you send a new podcupdate.
Yes I know, but the last output I posted is actually the answer for the forced PODC update (tried that several times): 21:42:21

exec podcupdate true
21:42:21

{
"Command": "podcupdate",
"PODCUpdate": "Processed (1) over 0 CPID(s) successfully."
}
|
|
|
|
BiblePay
1.1.9.7 - Leisure Upgrade
- Slow down POG leaderboard UI refresh
- Speed up boot time
- Fix bug where PODC update is unable to find destination address
- Fix mining crash in windows 10
Could someone please tell us if this fixes the crash in windows 10. Also, we had complaints of someone trying to do 'exec podcupdate' and receiving "Invalid Destination Address". This fixes that problem.
Also: This wallet fixes the problem where a person is unable to run 'exec podcupdate true' because the transaction is rejected. Please try again in this version.
I realized that I missed PODC payment yesterday because my wallet got confused with POG and PODC and somehow touched my PODC pile so that my specified utxoamount wasn't met anymore. Today in the morning I tried to send PODCupdate true, but got the "invalid destination address" error. I didn't have time then to do anything about it. Now I read that you already fixed this error. However for me it seems to have caused an even "worse" situation: my wallet (1198) doesn't even read out my RAC anymore. This is how it looks like: "Command": "getboincinfo",
"CPID": "7c9264559fef3c1c689ee9fc3ff42494",
"Address": "BNetxsZfjyNfW73Kvsh5AYLHENpEHcR3qh",
"CPIDS": "7c9264559fef3c1c689ee9fc3ff42494;",
"CPID-Age (hours)": 431011,
"NextSuperblockHeight": 104970,
"NextSuperblockBudget": 998673,
"Total_RAC": 0,
"Total Payments (One Day)": 0,
"Total Payments (One Week)": 61522,
"Total Budget (One Day)": 998673,
"Total Budget (One Week)": 7066751,
"Superblock Count (One Week)": 8,
"Superblock Hit Count (One Week)": 8,
"Superblock List": "104765,104560,104355,104150,103945,103740,103535,103330",
"Last Superblock Height": 104765,
"Last Superblock Budget": 998673,
"Last Superblock Payment": 0,
"Magnitude (One-Day)": 0,
"Magnitude (One-Week)": 8.705839501066333 "Command": "totalrac",
"Total RAC": 0,
"UTXO Target": 10,
"StakeBalance": 2586156,
"Threshhold to receive 10% rewards (below this UTXO Amount rewards are lost)": 10,
"Stake Level Required For 10% Level": 10,
"Stake Level Required For 20% Level": 10,
"Stake Level Required For 30% Level": 10,
"Stake Level Required For 40% Level": 10,
"Stake Level Required For 50% Level": 10,
"Stake Level Required For 60% Level": 10,
"Stake Level Required For 70% Level": 10,
"Stake Level Required For 80% Level": 10,
"Stake Level Required For 90% Level": 10,
"Stake Level Required For 100% Level": 10,
"Total Team RAC": 5793726 "Command": "podcupdate",
"PODCUpdate": "Processed (1) over 0 CPID(s) successfully." Any ideas? Right now it looks like I'm gonna miss out the second PODC payment in 3 days. |
|
|
|
# mempool tx: 1
=> manual tithe works perfect
=> # mempool tx: 4
=> tried manual tithe again: works after approx. 2 minutes
=> further manual tithes also seem to work, # mempool tx is rising (currently 11)
I'd try tithe=5 (every 5 minutes) Anything useful coming from your debug.log? I'm not able to tithe and there's lines like this: 2019-03-01 19:20:35 BiblePayMiner::Choosing to tithe with coin age 2.650532 and coin amount 1087.001000 with a total tithe amount of 9.610000 with current pog difficulty of 2522.398416 with buffered tithe amount of 8.168500. CreateTransaction::Requiring specific coin age 2.932500 and coin amount 963
BiblePayMiner::SendTithe::Error - Unable to send tithe - Amount 9.610000, Error Unable to Create Transaction: Unable to locate coins older than minimum_tithe_coin_age.
Yes, I find those kind of errors too, but they are quite rare. Maybe the wallet waits for a prolonged time after this? I also tested faster manual tithing right now, and I could practically tithe successfully every 4 or 5 seconds. Well I'll just leave the wallet running with tithe=5 over night. Thanks for your help! Anyway, I |
|
|
|
|
Show Posts
