|
Everyone, please check your POW difficulty. If its less than 1000, you may be on a fork.
If so, please delete your blocks and chainstate folder and restart.
|
|
|
|
BiblePay
1.1.4.4 - Leisure Upgrade
- Implemented faster boot time (90% faster on Linux, 40% faster on windows); Note that the first cold boot will be approx. 50% faster, then successive cold boots 90% faster on linux.
- Ensure PODC updates transmit for both Rosetta and WCG automatically
- Added checkpoint at block 63000
- Checked in MIPs Mac Build Configuration
The download from biblepay.org still seems to be 1.1.3.8 Oddly last night a few of my miners ended up on different forks at block 63828 8c53f3d28f18180a78d8fde6ce2fcb2ecee4f57ac7d3a31297848915f8d1938e 846572421ddf51d629b236f79e6f6af8c8a079baf5e45625c70646ec12d85ba3 Anyone else see this? I do confirm we had a release problem. I found a bug in the release script; fixed. The new version should be out now. On a side note: If your boot speed does not change on windows, please delete blocks and chainstate and re-sync (but only if you boot a few times and it is still slow). I'll re-test windows to try to find the remaining (fast speed during memorizeprayers) incompatibility. |
|
|
|
|
BiblePay
1.1.4.4 - Leisure Upgrade
- Implemented faster boot time (90% faster on Linux, 40% faster on windows); Note that the first cold boot will be approx. 50% faster, then successive cold boots 90% faster on linux.
- Ensure PODC updates transmit for both Rosetta and WCG automatically
- Added checkpoint at block 63000
- Checked in MIPs Mac Build Configuration
|
|
|
|
Rob, I tried migrating completely to WCG to test this last week and noticed my wallet stopped sending PODC updates after a week. I read through my log and discovered that after suspending Rosetta on each machine, the first number in my PODC Updates steadily decreased. It went from "PODCUpdate Processed (7) over 1 CPID(s) successfully" down to "PODCUpdate Processed (1) over 1 CPID(s) successfully." and then finally PODCUpdate Processed 0 tasks for CPID. At this point, my wallet transaction list no longer showed PODC updates. I tried manually running "exec podcupdate true" but it would fail and say Processed (0). Only until I took one of my machines and started crunching Rosetta again, was I able to get it to run PODC updates once again automatically.
Do you think you could explain this? Thanks!
I'm experiencing the same issue right now. Few days after I solved my last Rosetta task, I stopped receiving rewards - the wallet is not sending PODC updates. "exec podcupdate true" it would fail and say Processed (0) tasks. I think you guys do have a point here. The wallet does have a spork (a network config setting) that dictates if it should be counting task weight per project, but I dont believe its honoring that setting from the PODC Update perspective. So for now you can get around this by typing: exec podcupdate true (that means force=true) if you are wcg only, do this once per day, but yes, I need to take a look at this as this is exactly the kind of thing new users hate. Hi Rob, I tried PODC update true, but it refuses to work when no Rosetta hosts are crunching. I had a quick look at the rpcblockchain.cpp. I notice that PODCUpdate function will return false if iInserted == 0. iInserted seems to only be incremented in a loop that iterates through all the BOINC hosts that a user has extracted from GetBoincHostsByUser. Given that GetBoincHostsByUser is passed the argument "project1", does that mean only hosts crunching Rosetta are counted? Because if so, that would explain why an individual with WCG only hosts would be unable to send PODC updates. Sorry my coding skills are a bit rusty, and I'm not very familiar with the BBP source. Please correct if I'm wrong. I'll take a look at this today, maybe we need a leisure to fix this; and we can roll out the fast boot feature at the same time. This will be fixed in a few hours as a leisure. In this way WCGs or Rosetta PODC updates should go through automatically starting in version 1.1.4.4. |
|
|
|
I tried to comment but they removed my comment as they said I must have 19 total reddit comments before posting, but Ive posted comments in your forums before. I was basically going to say our average volume does allow us to spend over $130,000 per year on charity - the math is simple - 2 days of liquidations on c-cex per month only equals $13,000 and aligns with our average volume. |
|
|
|
Our wiki is throwing "resource limit exceeded" errors. Just an fyi that it should probably be looked at to see what sort of traffic is coming in.
Thanks - it looks like a wordpress issue on www.biblepay.org is taking down the wiki subdomain. Ill try to trace which plugin is consuming all RAM. EDIT: It was a d-dos attack. We blocked the perpetrator. |
|
|
|
Rob, I tried migrating completely to WCG to test this last week and noticed my wallet stopped sending PODC updates after a week. I read through my log and discovered that after suspending Rosetta on each machine, the first number in my PODC Updates steadily decreased. It went from "PODCUpdate Processed (7) over 1 CPID(s) successfully" down to "PODCUpdate Processed (1) over 1 CPID(s) successfully." and then finally PODCUpdate Processed 0 tasks for CPID. At this point, my wallet transaction list no longer showed PODC updates. I tried manually running "exec podcupdate true" but it would fail and say Processed (0). Only until I took one of my machines and started crunching Rosetta again, was I able to get it to run PODC updates once again automatically.
Do you think you could explain this? Thanks!
I'm experiencing the same issue right now. Few days after I solved my last Rosetta task, I stopped receiving rewards - the wallet is not sending PODC updates. "exec podcupdate true" it would fail and say Processed (0) tasks. I think you guys do have a point here. The wallet does have a spork (a network config setting) that dictates if it should be counting task weight per project, but I dont believe its honoring that setting from the PODC Update perspective. So for now you can get around this by typing: exec podcupdate true (that means force=true) if you are wcg only, do this once per day, but yes, I need to take a look at this as this is exactly the kind of thing new users hate. Hi Rob, I tried PODC update true, but it refuses to work when no Rosetta hosts are crunching. I had a quick look at the rpcblockchain.cpp. I notice that PODCUpdate function will return false if iInserted == 0. iInserted seems to only be incremented in a loop that iterates through all the BOINC hosts that a user has extracted from GetBoincHostsByUser. Given that GetBoincHostsByUser is passed the argument "project1", does that mean only hosts crunching Rosetta are counted? Because if so, that would explain why an individual with WCG only hosts would be unable to send PODC updates. Sorry my coding skills are a bit rusty, and I'm not very familiar with the BBP source. Please correct if I'm wrong. I'll take a look at this today, maybe we need a leisure to fix this; and we can roll out the fast boot feature at the same time. |
|
|
|
Rob, I tried migrating completely to WCG to test this last week and noticed my wallet stopped sending PODC updates after a week. I read through my log and discovered that after suspending Rosetta on each machine, the first number in my PODC Updates steadily decreased. It went from "PODCUpdate Processed (7) over 1 CPID(s) successfully" down to "PODCUpdate Processed (1) over 1 CPID(s) successfully." and then finally PODCUpdate Processed 0 tasks for CPID. At this point, my wallet transaction list no longer showed PODC updates. I tried manually running "exec podcupdate true" but it would fail and say Processed (0). Only until I took one of my machines and started crunching Rosetta again, was I able to get it to run PODC updates once again automatically.
Do you think you could explain this? Thanks!
I'm experiencing the same issue right now. Few days after I solved my last Rosetta task, I stopped receiving rewards - the wallet is not sending PODC updates. "exec podcupdate true" it would fail and say Processed (0) tasks. I think you guys do have a point here. The wallet does have a spork (a network config setting) that dictates if it should be counting task weight per project, but I dont believe its honoring that setting from the PODC Update perspective. So for now you can get around this by typing: exec podcupdate true (that means force=true) if you are wcg only, do this once per day, but yes, I need to take a look at this as this is exactly the kind of thing new users hate. |
|
|
|
Apart from the new Exchange, BBP should invest as much as possible in Digital Marketing to motivate traders to invest in BBP. We should not put all the hope (and budget) on a new exchange. There are dead coins on very good exchanges in fact. Today's world is driven by marketing.
Agree. Agreed. I feel a big exchange *will* pick us up eventually and we should work on all the other aspects in the interim. |
|
|
|
I got my payments on PODC and I am happy  , now i have two questions: 1) Rosseta seems to take a lot of network traffic and space. Question: Do I have to be "boinc"ing at least one station on Rosseta, or can I move all my boinc stations to WCG ? 2) West said in the past that we could use WCG RAC to receive payment from GByte coin. Today GByte coin asks to change WCG user name to be something else. Question: If i would change WCG user name, will it be effecting Biblepay PODC payment ? You can actually stop Rosetta and go 100% WCG. The only side element to this is for brand new users who do not have a Rosetta account. There is a small chance a person who started fresh on WCG with no Rosetta account will need to create a rosetta account to ensure the cpids match across projects, then stop boincing rosetta later. But for you, you can just turn off rosetta. The entire issue is for CPID synchronization. WCG does honor boincs 'externalcpid' field (which is what we honor also). On #2, I cant offer assistance here. |
|
|
|
Hehe Official answer via cryptonex bitcointalkforum: Hello! Yes, Vladimir Savvon is Cryptonex CMO and pr@cryptonex.org is his email address. You can discuss listing issue with him. So slovakia was right and his communication was correct. Hawk. Yes its correct now, lol. |
|
|
|
I hope that with the changes that have taken place with the system, it is again stable or, at least, will solve the current problems.
The GDPR saga was temporary and they backed down, the WCG problem is solved? Do you mean heat mining against purepool? |
|
|
|
a few things concern me about coinexchange.io listing.
Pro: "Terra Nova Coin" appears to be another "charity" coin. But the transaction history appear pump and dump nature ... (giant doji up and all the way back down a few times)
Con: their "highest volume" coin (700k USD) appears to no longer be listed(and no longer exists)
I'm not a sanctuary so I cannot vote.. but this exchange seems desperate for relevancy. I don't see the value in paying 2 BTC for them.
Edit:
I'm a firm believer in taking time and praying before a big decision... The fact that they want to close quick concerns me.
We've been looking at coinexchange.io for 8 months now, their volume has been showing to be 40% higher than c-cex (back when both were active on coinmarketcap). We don't have other offers... All the junk people are posting here over 24 hours is just spam. It takes time to receive a hard offer from an exchange and verify the offer is not a scam. Remember we got scammed at yobit for .10 recently in the same way. I applied at bitfinex yesterday and we have a ticket inside the bitfinex portal. Znffal is the one who has the master exchange spreadsheet and has been contacting our exchanges. As far as closing quick, we've been replying to them for 4 months and explaining we have been saving up, but they gave us a deadline for the deep discount offer. I see Linda is doing $8100 a day there, thats not bad and not far off of our project. Doge $60,000 a day. Yes I agree on the praying and taking time. I think in this case we were praying they didn't remove the offer as its our only good offer, and our main exchange is always on vacation and we have no other liquidity. Our perspective in the e-mails was that 'coinexchange' was a pretty good exchange. Yours seems to be as if this offer just appeared  , so I think we have a different perspective on this one. |
|
|
|
*** EMERGENCY VOTE REQUIRED FOR SANCTUARIES - VOTE TO BE LISTED ON COINEXCHANGE.IO WITHIN THE NEXT 72 HOURS ***
Please see this proposal: https://forum.biblepay.org/index.php?topic=231.new#newYou may vote in the wallet or in the pool. Please wait 45 more minutes for the proposal to be active.
|
|
|
|
I see no variation between ours and Dash's... I have isolated the loop that takes the time, I don't see a clear way to optimize it more.
Something of note I placed a counter to capture blocks it processes: blocks processed = 63286
This is 358 blocks more than the chain has currently. I suspect these are "orphan" chains/blocks that need to be accounted for and routed through before settling on the current active.
I will keep digging to see if we can isolate these from the loop and see if it would speed up the process
THANK YOU very much! Looks like we need to go in with a more advanced test harness and see if it has something to do with our block.vtx[n].sTxOutMessage. Those messages are limited to 3000 bytes each, so I didn't expect those to be the issue, but if they are being hashed, it could be part of the delay. Hmm... so revisiting my test showed an error. Apparently the microseconds timestamp is not returning microseconds but milliseconds. This accounts for the odd times of 0ms then a batch of "catchup" time. it seems to process a range of 300-700 blocks per milli-second. will continue testing. The area that is taking 30sec is the boost foreach loop in "bool static LoadBlockIndexDB()" You might be on to something with the boost foreach, thanks, thats interesting. Im going to try it without boost later today. Unfortunately I have a lot of Biblepay emails to respond to and some might take hours - weve got exchange questions, Bhavanis in-depth stock market emails, creating a dog & pony show, etc, hours of fun. I found the specific load lag issue, so don't worry about it- Ill be checking in a patch soon that resolves both the index & the prayers. |
|
|
|
As you all know recently we had multiple community members wanting to help get us listed on several exchanges at once that we have not contacted. Some had technical questions for me, etc, as some of these answers on exchange requirement forms are not readily apparent. In an effort to streamline the answers I made a wiki page you can refer to: https://wiki.biblepay.org/CoinExchange_RequirementsPlease if anyone finds an error or an enhancement please advise. |
|
|
|
I see no variation between ours and Dash's... I have isolated the loop that takes the time, I don't see a clear way to optimize it more.
Something of note I placed a counter to capture blocks it processes: blocks processed = 63286
This is 358 blocks more than the chain has currently. I suspect these are "orphan" chains/blocks that need to be accounted for and routed through before settling on the current active.
I will keep digging to see if we can isolate these from the loop and see if it would speed up the process
THANK YOU very much! Looks like we need to go in with a more advanced test harness and see if it has something to do with our block.vtx[n].sTxOutMessage. Those messages are limited to 3000 bytes each, so I didn't expect those to be the issue, but if they are being hashed, it could be part of the delay. Hmm... so revisiting my test showed an error. Apparently the microseconds timestamp is not returning microseconds but milliseconds. This accounts for the odd times of 0ms then a batch of "catchup" time. it seems to process a range of 300-700 blocks per milli-second. will continue testing. The area that is taking 30sec is the boost foreach loop in "bool static LoadBlockIndexDB()" You might be on to something with the boost foreach, thanks, thats interesting. Im going to try it without boost later today. Unfortunately I have a lot of Biblepay emails to respond to and some might take hours - weve got exchange questions, Bhavanis in-depth stock market emails, creating a dog & pony show, etc, hours of fun. |
|
|
|
Im confused by some previous responses though, because in order to PODC mine with BiblePay you need coins staked, which means if you really want to mine to your full potential, you need to buy some BBP. But how many miners are buying coins for staking? and how much are they buying? I dont know. Opening up the team requirement could have a lot of benefits, but I could see miners being against this, more competition meaning less profit, These new miners would still have to install BiblePay wallet to do CPID burn address, and then they would still have to buy BBP in order to do staking. Right? Some of these miners could potentially convert and become BiblePay fans Someone mentioned miners wont mine if we are illiquid, but I dont think we are *that* illiquid (yes we are illiquid since ccex is on vacation and buying is low, but thats generally affecting our large liquidations) however I feel the impact of small miners is low, in the sense that a person who desires to sell coins to pay for VMSs will basically drive up our volume (they would be forced to sell .01 below the market, and value buyers buy that up). Its also true that even if we removed the team requirement, as the rules are now you still have to buy BBP to stake which helps our price, and as Togo said there are a certain % of converts who are going to stay with biblepay if we do this. Im floating the idea as a lower bar of entry for the 50,000 boinc accounts out there who may want to be compensated for researching but have a strong affinity to the current team. People like the US Navy, Oracle, overclocking forums, etc. <- One downside to doing this is then we lose all sense of organization in our reports for our team (IE the team report becomes pretty worthless) and all statistics become worthless. But yes, the fact that you have to buy bbp on an exchange to mine is still a large hurdle for non-crypto enthusiasts. |
|
|
|
|
Show Posts
