Ok, redirected to web where they can find expenses and revenue. |
|
|
|
MIP mentioned to me via email that the mobile wallet needs to be updated to 70750, which was just released yesterday at 10am.
Please upgrade and let us know if it syncs to the top height?
Looks like I'm on the latest version, since I have installed the mobile wallet just yesterday. I have checked for updates right now just in case and there was no any updates at all. Furthermore, something strange is going on with my desktop wallet.  All transactions before Dec. 26th are valid, this large transaction at Dec. 26th is "not confirmed, not in mempool", and in spite that my balance was not zero after this transaction now the wallet only displays latest transaction as my final balance.  Also, where are all transactions (mined blocks) between Dec. 21st and Dec. 26th? May be all that above means that BBP experienced an occasional network fork and I was mining on some secondary chain?... That would be really sad... I'm sorry to see that you might have mined on a fork and lost some bbp mined off the main chain, but we must move forward. Ill post my hypothesis. First, note that in our 2 year history this is the first mandatory where the network required our users to upgrade before the mandatory cutover height. We had an increase in our governance protocol version to 70750 from 70737, and when 60% of our sancs moved to 70750, the older biblepay clients stopped recognizing those sanctuaries as official, meaning they then need to upgrade early (or go on a fork) - this explains why 75% of our network upgraded 3 days early (we were shooting for Dec 26th and all this happened around Dec 23rd). So apparently what happened is you mined on the prior version, 1 mil bbp on the low diff chain. When you upgraded, all the blocks mined on the side chain got erased. Notice how your outbound transaction to your mobile is orphaned also. Thats because it was sent on a sidechain, and the txid is not on the main chain. The reason your last mined transaction is in immature is because its not 120 deep yet but its probably officially mined. Just run the client with -zapwallettxes=1 and restart and it will fleece the orphans out of the wallet - note it will remove all the mined and the outbound tx and leave all official txes. Good luck going forward. |
|
|
|
Rob, Togo, & Sunk, it appears that my wallet is back in business and I even associated my CPK for PoDC 2.0. Thanks again for the suggestions and assistance. You guys have been busy. Don't forget to rest and enjoy the holidays.  So I suppose the actual problem then was your IP was in the dns1-4's nodes banlist.dat (probably for 24 hours due to an unforgiveable sin lol, what I mean is something like transmitting a bad block header - which happens if your client is on an old version and mining alone, etc.) and we had to delete banlist and reboot dns1 to get your node to automatically see. The add ips the others posted might have contained a very old list of nodes that were down. One other side note, if anyone can get a list of the current sancs, those also work as external nodes for someone in need of an addnode. (IE masternodelist full; those are all external nodes). Thats imho, a better practice for us to paste in the future, as we know they are up. If you do that please post a few IPs that are 40000 (not dynamic IPs) to help the user. Dynamic IPs dont answer - they are non 40000 ports. Glad you are up man! Happy holidays. |
|
|
|
Good point. And as a reminder: Christian treasure trove, info about the Vatican and false pope, Rapture videos, Christian content, BMS Edge nodes, DSQL, Cloudflare stream, resilient hosting, uptime during the tribulation in local areas, utility (pay to lease or pay to download), NAS based docker build for biblepay and bms and mssql, etc. |
|
|
|
Let's welcome the following users to the BiblePay team:
fallen1
uptimeminer
amygdala
jaapgvk
murof
adieslate
jackie1400
Radiant
easyrhino
Tin Tran
MrCoin
dave_boinc
Millerpr
littlebro
Kismar
Tom24
Great, its good to see more than one new user coming in per day again, its been a long time. Ill look into sending a mass mailing to our 4,500 pool recipients within 30 days. |
|
|
|
is any problem with PODC  There is not really a major problem, just a glitch in this first version. Please reboot the client then type 'exec rac' again and everything should be OK. Im working on fixing that. It does recover by itself after 4 hours. If its been 4 hours please try exec rac again. |
|
|
|
Oh we have two, ok, Im compiling a new wallet now to diagnose this.
Ill check both. Its hard to believe that on the go-live date, WCG would have a bad file, but let me keep checking. @capulo - quit bbp wallet, and try erasing SAN/wcg.rac, restart wallet Is the RAC the explicit value from WCG user.gz ? Looks like what I see in BiblePay debug.log (referenced by SAN/wcg.rac I assume, is an old file from Dec 14th.) GMT: Thursday, December 26, 2019 6:14:45.930 PM Your time zone: Thursday, December 26, 2019 10:14:45.930 AM GMT-08:00 Relative: 4 hours ago GMT: Saturday, December 14, 2019 6:12:02.292 PM Your time zone: Saturday, December 14, 2019 10:12:02.292 AM GMT-08:00 Relative: 12 days ago I see from Dec 13, the RAC for capulo was about 91k  <user>
<id>1066130</id>
<name>capulo</name>
<country>SLOVAKIA</country>
<create_time>1523366299</create_time>
<total_credit>73312472.726368</total_credit>
<expavg_credit>124044.285283</expavg_credit>
<expavg_time>1577384085.930994</expavg_time>
<cpid>e7c056024cd3b781edd5af37965c652c</cpid>
<teamid>35006</teamid>
</user>
From the latest debug.log, I see the following of 91k RAC <user>
<id>1066130</id>
<name>capulo</name>
<country>SLOVAKIA</country>
<create_time>1523366299</create_time>
<total_credit>71695793.027780</total_credit>
<expavg_credit>91775.569413</expavg_credit>
<expavg_time>1576347122.292800</expavg_time>
<cpid>e7c056024cd3b781edd5af37965c652c</cpid>
<teamid>35006</teamid>
</user>
where is user.gz file? but you are right, if you check total credit, it also goes down so it is historical data ps: now i see 124k rac, seems ok (i did only restart) No the client isnt looking for that user.gz file, he was making an assumption. The problem has been resolved, lets wait for the sanctuaries to resync and verify the upcoming leaderboard looks correct now. |
|
|
|
I saved all of the data and exposed it at : http://san.biblepay.org/ but we will need to remove the "/SAN/" part of the URL to access the file. The letter rewards are discontinued, since we don't have any orphans sponsored by the foundation (in approx 20 more days they stop) so currently its the responsibility of the POOM sponsor to write letters. But I do plan on writing the write letter flow again in DSQL some day - once we either need it again - or when we design decentralized sponosrships 3.0 (something with decentralized keys). There are no gospel link rewards, but, the user can watch the links for free now at web.biblepay.org by clicking gospel links. Ill look into redirecting pool.biblepay.org to web.biblepay.org now. Togo, dont worry about updating the links, I believe I can move the whole domain to one of our other servers and redirect the links. Let me check into that. Ok, the contents of the san have been mirrored to another location and the links work again, but note, some links might be broken due to platformization issues; so if you find a broken link, first try prefixing it with /SAN/ if that is missing, otherwise let me know and Ill fix the case of the URL: http://pool.biblepay.org/SAN/Docs/SponsorshipsAugust2018.pdfEDIT: Ok, https works now. Also, Togo if you need me to mirror /SAN/Docs to /Docs I can do that, let me know. At that point the only issue is case sensitivity as linux is case sensitive where windows was not. |
|
|
|
Can you evaluate with MIP? |
|
|
|
Ok I started a thread with Todd, we will discuss the 30 mil and figure it out. |
|
|
|
I saved all of the data and exposed it at : http://san.biblepay.org/ but we will need to remove the "/SAN/" part of the URL to access the file. The letter rewards are discontinued, since we don't have any orphans sponsored by the foundation (in approx 20 more days they stop) so currently its the responsibility of the POOM sponsor to write letters. But I do plan on writing the write letter flow again in DSQL some day - once we either need it again - or when we design decentralized sponosrships 3.0 (something with decentralized keys). There are no gospel link rewards, but, the user can watch the links for free now at web.biblepay.org by clicking gospel links. Ill look into redirecting pool.biblepay.org to web.biblepay.org now. Togo, dont worry about updating the links, I believe I can move the whole domain to one of our other servers and redirect the links. Let me check into that. Ok, the contents of the san have been mirrored to another location and the links work again, but note, some links might be broken due to platformization issues; so if you find a broken link, first try prefixing it with /SAN/ if that is missing, otherwise let me know and Ill fix the case of the URL: http://pool.biblepay.org/SAN/Docs/SponsorshipsAugust2018.pdfEDIT: Ok, https works now. |
|
|
|
I saved all of the data and exposed it at : http://san.biblepay.org/ but we will need to remove the "/SAN/" part of the URL to access the file. The letter rewards are discontinued, since we don't have any orphans sponsored by the foundation (in approx 20 more days they stop) so currently its the responsibility of the POOM sponsor to write letters. But I do plan on writing the write letter flow again in DSQL some day - once we either need it again - or when we design decentralized sponosrships 3.0 (something with decentralized keys). There are no gospel link rewards, but, the user can watch the links for free now at web.biblepay.org by clicking gospel links. Ill look into redirecting pool.biblepay.org to web.biblepay.org now. Togo, dont worry about updating the links, I believe I can move the whole domain to one of our other servers and redirect the links. Let me check into that. |
|
|
|
it dropped by 30k in one day  Ok, the problem with the RAC is fixing itself now. For some reason 12 hours ago was correct, but this mornings RAC dump was wrong, so the network is re-downloading the rac now, and within the next 100 blocks or so the sancs should see the correct rac. If you reboot your client you should see the correct rac right now, but sancs will take a little while to update (I believe its every 50 blocks or so). I don't believe this will be a reocurring issue knock on wood, as we didnt run into this in testnet. |
|
|
|
I saved all of the data and exposed it at : http://san.biblepay.org/ but we will need to remove the "/SAN/" part of the URL to access the file. The letter rewards are discontinued, since we don't have any orphans sponsored by the foundation (in approx 20 more days they stop) so currently its the responsibility of the POOM sponsor to write letters. But I do plan on writing the write letter flow again in DSQL some day - once we either need it again - or when we design decentralized sponosrships 3.0 (something with decentralized keys). There are no gospel link rewards, but, the user can watch the links for free now at web.biblepay.org by clicking gospel links. Ill look into redirecting pool.biblepay.org to web.biblepay.org now. |
|
|
|
My RAC is 23 000, cpid 982538340112287ed60723499adfeb4b is ok, WCG nickname is Sakic. https://www.boincstats.com/stats/15/user/detail/1065623something must be wrong, because nickname Byteball_72ec2753 is my old nickname I used a long time ago with PODC 1.0. As I said, it was everything corect 2 days ago when I set up PODC 2. I already got reward for my RAC 22000 that time. It looks like boinc export file picks old data. Wait, before I look I think I remember the problem. In your WCG account, can you please navigate to Data Sharing, and verify the radio button is enabled for Export Data = OK? I think due to GDPR regs, this is the process that 'suspends' your export. Please let me know once you change that, and if you had to change it, so I can do some tests. EDIT: Its in settings : "Step 3", "Click Settings | Data Sharing. Ensure the 'Display my Data' radio button is selected. Click Save. Yes, radio button "Display my Data" is already selected. Oh really, great, I have work to do! Ok let me look into the underpinnings now. rob, same here, rac is wrong it dropped by 30k in one day 08:28:54  { "Command": "rac", "cpid": "e7c056024cd3b781edd5af37965c652c", "CPK": "BREpeasoDxk7KWGpf2iJaW39Kb9DFj7Pou", "wcg_teamid": 35006, "next_podc_gsc_transmission": 165947, "team_name": "Biblepay", "researcher_nickname": "capulo", "researcher_country": "SLOVAKIA", "total_wcg_boinc_credit": 73122217.66, "total_wcg_points": 511855523.62, "external_purse_total_coin_age": 47297691.11784723, "coin_age_percent_required": 0.09506260831199641, "coin_age_required": 4023264.973619231, "wcg_id": 1066130, "rac": 120349.72572 } 21:36:41  exec rac 21:36:41  { "Command": "rac", "cpid": "e7c056024cd3b781edd5af37965c652c", "CPK": "BREpeasoDxk7KWGpf2iJaW39Kb9DFj7Pou", "wcg_teamid": 35006, "next_podc_gsc_transmission": 165947, "team_name": "Biblepay", "researcher_nickname": "capulo", "researcher_country": "SLOVAKIA", "total_wcg_boinc_credit": 71695793.03, "total_wcg_points": 501870551.21, "external_purse_total_coin_age": 52856205.09770833, "coin_age_percent_required": 0.06351175998850314, "coin_age_required": 2828428.561091664, "wcg_id": 1066130, "rac": 91775.569413 } in themorning it was ok, now not Oh we have two, ok, Im compiling a new wallet now to diagnose this. Ill check both. Its hard to believe that on the go-live date, WCG would have a bad file, but let me keep checking. |
|
|
|
Yes, radio button "Display my Data" is already selected. I think you should try again: exec associate sakic verification_code true then wait a few hours and look at exec rac yesterday, I had my android account show up and I had to re-do my exec associate No, in his case he is associated (because I see his CPID and CPK), but system wide its showing .08 rac for him (and he should be 20K+). Still checking... |
|
|
|
Thanks Togo. Giving that a try now.
Looking at our 4 dns servers, I see the problem, apparently when we switched to dynamic ports, we no longer listen on 40,000 by default in these core nodes. I just updated all 4 to use the 40,000 default ports. Please try now. Also please ensure your system time is correct. Nothing changed over night. Just restarted the client but nothing yet. I will check back when the family is done with opening gifts. This can be fixed in minutes... We just need you to confirm that your system time and timezone is correct, and post your IP, and then I can check the DNS1 log and unban you. Or you can add an addnode like they suggested. DNS1-4 is working. I actually already posted in previous posts that the time/date were correct. (yes I manually sync'd it to verify) I have also posted adding the nodes as both Togo and Sunk suggested. So, I guess all that is left is my IP address. Currently it is 107.77.210.51 Edit: I want to say it was Sunk that posted about this site earlier, but they have a faucet with BBP that new users could utilize for setting up PoDC. https://freefaucet.io/login/register.php?r=cl3dkde3mhcz2yj It is a small amount each time but it is something to get started. We can certainly debug this because weve been through this end to end, it can only be one of about 10 things. Could you please try this first: rm banlist.dat. rm debug.log (I ensured our banlist.dat was cleared on our first dns1 node, so your IP is not blocked). First just start the node. If no connections: addnode dns1.biblepay.org onetry If still no connections, try restarting again with "-erasechain=1". Just to be sure there is no data in there being passed off on other nodes (bad blocks). If still no connection could you please post the log snippet - that should show the reason you cant connect. One last thing to try ./biblepay-qt -connect=dns1.biblepay.org And: telnet dns1.biblepay.org 40000 I confirm the seed node is running and listening and synced, etc. I am using windows 10 if that helps. Here is the odd part. I removed the nodes to start clean and now it seems to be connecting on its own. (unless you had actually de-banned the ip already) I will see how it goes and report back from there. Thanks for taking the time to assist thus far. Oh OK, yes, although I did remove our banlist.dat and reboot dns1, I was just thinking what probably happened. You probably banned the main external nodes, because when you deleted banlist.dat, you found a connection. So all, lets remember this for next time: We should remove our own banlist.dat first, then restart. |
|
|
|
My RAC is 23 000, cpid 982538340112287ed60723499adfeb4b is ok, WCG nickname is Sakic. https://www.boincstats.com/stats/15/user/detail/1065623something must be wrong, because nickname Byteball_72ec2753 is my old nickname I used a long time ago with PODC 1.0. As I said, it was everything corect 2 days ago when I set up PODC 2. I already got reward for my RAC 22000 that time. It looks like boinc export file picks old data. Wait, before I look I think I remember the problem. In your WCG account, can you please navigate to Data Sharing, and verify the radio button is enabled for Export Data = OK? I think due to GDPR regs, this is the process that 'suspends' your export. Please let me know once you change that, and if you had to change it, so I can do some tests. EDIT: Its in settings : "Step 3", "Click Settings | Data Sharing. Ensure the 'Display my Data' radio button is selected. Click Save. Yes, radio button "Display my Data" is already selected. Oh really, great, I have work to do! Ok let me look into the underpinnings now. |
|
|
|
|
Show Posts
