16:01:12

{
"Command": "getboincinfo",
"CPID": "c117f5ddc829b502ea8cd00647585856",
"Address": "BQ1hGzcegB9e1LvCNX6oVpUjPVPy6BcPN8",
"CPIDS": "c117f5ddc829b502ea8cd00647585856;",
"CPID-Age (hours)": 424473,
"NextSuperblockHeight": 50635,
"NextSuperblockBudget": 1144187,
"c117f5ddc829b502ea8cd00647585856_ADDRESS": "BQ1hGzcegB9e1LvCNX6oVpUjPVPy6BcPN8",
"c117f5ddc829b502ea8cd00647585856_RAC": 9409.379999999999,
"c117f5ddc829b502ea8cd00647585856_TEAM": 15044,
"c117f5ddc829b502ea8cd00647585856_WCGRAC": 122,
"c117f5ddc829b502ea8cd00647585856_TaskWeight": 100,
"c117f5ddc829b502ea8cd00647585856_UTXOWeight": 208165,
"Total_RAC": 9531.379999999999,
"Magnitude (One-Week)": 0.1867795509395137
}
Hi folks, please help. My last recieved payment PODC was 50020, I am not receive 2 PODC payment 50255 & 50430. Wallet and PODC still online. In addition to what Licht said if you type exec utxoreport cpid, You will see you sent a lot of 1's for the utxo (and the latest 1 in the chain overrides any existing utxos until a new utxo is sent). |
|
|
|
I didn't want to have to read through 400+ pages. However, I'm not seeing anything clarifying how to add WCG. I see adding Rosetta. If someone has the CPID from Rosetta already associated with their account and their CPID with WCG is the same, does that automatically opt them in to PODC with WCG as well or is there another step needed? I could see it beneficial and hindering both at the same time depending on situation. I'm always supporting WCG but only support Rosetta during challenges normally.
Also, are you basing the RAC off of what the project site is reporting? I ask because that can take a few weeks to actually become accurate while running the project but becomes very inaccurate if you stop. For instance, I can stop running the project now and several weeks/months/possibly years I will continue to have a RAC at the project. You will find most projects never return you back to 0 RAC because of how RAC is calculated. I was just curious to which "report" I should watch for this...
Welcome aboard! To associate WCG with Biblepay, once you have Rosetta@Home crunching, just check the WCG web portal to ensure your CPID is the same as your RAH CPID. If it is different, just attach WCG to an existing machine that is crunching RAH, and also ensure your web portal WCG e-mail address matches your RAH e-mail address. Then within 24 hours of the next WCG work update, your CPIDs should match. Biblepay will automatically pick up your WCG credits. However, due to the GDPR issue, we are currently in the process of freezing WCG temporarily until the DPA issue is sorted out, so it is not a good time to start with WCG. Regarding diminishing RAC, yes it is true that BOINC'ers who had > 100 RAC and then stopped boincing now exist years later with a RAC of .01 (due to the fact that the RAC never really decays to 0). We filter these out by : requiring a payment of over 1 bbp, requiring recent RAC timestamps, and requiring tasks to be solved. So yes, if you stop boincing you will be paid for weeks as long as you are solving at least 1 task per day, but eventually this will stop when your daily payment decreases below 1 bbp. |
|
|
|
|
WCG Update :
(In a nutshell, we are still waiting for the DPA).
Robert,
You recently requested access to the World Community Grid data exports which, as mentioned previously, is dependent on you agreeing to our Data Processing Agreement (DPA). We wanted to update you on the status of the Agreement.
For months, we have been working with a team of lawyers to prepare World Community Grid for GDPR compliance and ensure adequate protection of our volunteers' data. It is no secret that many organizations have found it a challenge to adhere to this new, comprehensive and complex regulation, and frankly, we are no exception. It is also fair to admit that our lawyers have been far busier than normal helping various groups understand the implications of the regulation on their individual programs. We finally have a lawyer dedicated to finalizing the Agreement, but the review process is not yet complete.
Please know that we are doing everything we can to push this as aggressively as we can, and are using escalation channels to ensure this gets addressed as quickly as possible. We are fully aware of the impact of delaying access to the data exports has on you and sincerely appreciate your patience as we get this resolved.
Thank you for your support, during what has been (and continues to be) a challenging compliance process for us and many others.
World Community Grid Support Team
---------------------------------------------------------
World Community Grid
__________________
Hello again Robert,
We are working on getting a finalized DPA as quickly as we can.
Existing volunteers will be automatically opted in to having their data be public, but new volunteers will have to specifically opt in to making their data public (as they'll be opted out by default). And yes, the data exports will automatically exclude data of volunteers whose data can't be shared (either because they opted out, have chosen to delete their account, or we have deleted their account in accordance with our data retention policy).
Also - please note: Once a member has signed the DPA, they will be obligated to manually remove a member's stats who has requested their data be deleted. We will be providing a list of the members who have requested their data be removed, to those members who have signed the DPA and are using the API to export member stats.
Thank you for your support,
World Community Grid Support Team
---------------------------------------------------------
World Community Grid
|
|
|
|
hey Rob: this is answer from WCG Thank you for taking the time to contact us. As you've noticed, access to the APIs is now restricted to people who obtain a token. To get the token, you must first sign our Data Processing Agreement to ensure that you're willing to comply with certain requirements about how the API data must be processed. We are still finalizing the text of this Agreement and will email you as soon as it's ready if you would like - just let us know if you would like to be on the notification list. We have implemented the release which allows members to access their own API stats: https://www.worldcommunitygrid.org/forums/wcg/viewpostinthread?post=582183 Thanks for your patience as we continue to work aggressively to ensure compliance with the new EU General Data Protection Regulation and the protection of our volunteers' data. Thank you for your support, World Community Grid Support Team did you sign it? When you sign on, please read all prior posts. You seem to have a habit of making unholy posts and then being terribly ignorant about everything else. |
|
|
|
It is said that one great coder is 10x as good as a mediocre one.
Biblepay follows the benevolent dictator model (1 main dev) which generally leads to some of the best projects (software development).
One of the main reasons that I've always supported this project is because I believe in Rob's abilities and vision. Because at this point we have only one main dev, we have had the ability to be swift in our development (something that the past months also have shown). Having said that, I think that in the long term we need more developers that have understanding of our source-code (which I think Bhavani is working on at the moment?). So that, should Rob disappear for whatever reason, the coin will keep it's vitality. Yeah, the good and the bad of one dev is a good dev is better than two decent devs but you are locked into one ideal. That said, I agree, Rob has been tremendous and I don't think we'd be anywhere close to where we are if not for his skill and vision. I'd wager we'd be dying under the weight of a botnet by now with our value crushed if not for the change to PoDC. The code needs some cleaning up and I hope that is what Bhavani is working on, since there some conditional statements that need to be commented out or removed for clarity, that were part of the transition from one mandatory to another. Thanks for the compliments on part 1 of the post. However, I don't think you are correct on part 2. Conditional statements that are in the code from mandatory to mandatory are generally permanent, because the blockchain must sync from zero. Take a look at doge if you want an example of a lot of conditions that were added as business logic was added. These can only be removed if you decide to fork the coin and remove all prior business logic (IE break backwards compatibility). The statements are not intended to be easy for you to understand - they are intended to allow the blockchain to sync from zero with every prior pieces of business logic that existed over time. |
|
|
|
I'm curious about something I'm seeing in the masternode list. There are a few occurrences of multiple masternodes (or at least multiple txsigs) that are utilizing the same BBP mining address. For instance:
BBgWqkMQJXNioAgmJ8ZtMFzL51DWEBVomy has 2
BAqBZkMieZfES9LkVgcMmMPv3E68tZt9G8 has 3
B6JwmtM8fg3AwJjaKCV62zhX8CtLgrK6um has 2
Is that ok? Shouldn't there be a unique address generated for each masternode? It seems like the payments would get spread out too much otherwise, due to the algorithm that processes payments not being able to tell that these are distinct if it utilizes the BBP address rather than the txid for payment decisions (but I admit, I haven't checked that code out). Anybody know how that works?
Thats OK, because we pay by VIN not by address. The payment votes are tied to the VIN and the VIN is tied to the payment address. They apparently set them up without creating multiple addresses (like the guide shows). |
|
|
|
I got another PoDC payment at 2:05 and now again at 17:41. 15 hour difference. Looks like BBP day was shortened today. Maybe due to PoW difficulty or lack of PoDC payment prior?
To participate in these distributions, should have a minimum value of biblePay? Or does the algorithm randomly distribute the Biblepay? We assess your magnitude based on your BOINC RAC. We pay daily in our research superblock. So it is actually a relative daily distribution. |
|
|
|
I got another PoDC payment at 2:05 and now again at 17:41. 15 hour difference. Looks like BBP day was shortened today. Maybe due to PoW difficulty or lack of PoDC payment prior?
Looking at these two PODC blocks, they were 200 blocks apart (as expected), but that is fascinating, its almost as if the system was self correcting its time. I will need to analyze the difficulty levels in more detail to see if the issue was the low diff coming off the first PODC with CPIDs all of a sudden able to solve (due to having magnitude), IE an inrush of available miners. But that doesn't explain it because that would have driven DGW up, so this needs more analysis first. |
|
|
|
Thanks, not for the position we are in but its useful for others. There is a difference between the WCG API and the WCG daily export file. The API can be used with your own token and works for individual users. (Thats basically what that thread is referring to). But we dont use the API, we use the daily export file. We are still waiting for the Data Processing Agreement to be finished before we can apply for a token for downloading the daily dump files. I received a message from IBM today that they are still working on it. |
|
|
|
I remember a while ago Rob promised not to dump huge amounts but spread them over some periods. BBP is too weak so far to hold such blows
I've read Rob usually sells across 7 days to mitigate price drop. C-CEX is going on vacation tomorrow. So, you effectively have until today to finish the selling. Don't you think it is wise to sell BBP on the exchange before C-CEX goes on vacation for three months? What's the alternative, try your luck on a different exchange? I dumped the 7 million all at once because I wanted to withdraw it before the vacation started. I was going to split it up into 2 days, but during the last hour some mystery buyer came in with an order for 1.5 million BBP, so I dumped all of it at once. For the most part, we will try to spread it out, especially if the funds look tight, but in this case we only needed 2btc and the sales were for 2.03, so it all worked out in one session. |
|
|
|
very dangerous= this coin is independent only on 1 guy  why? "independent"? Sounds like you used the wrong word. But: Every small coin has this problem, a core developer who is responsible for a lot of work. It is true that we need for experienced blockchain developers to be a "mature" coin, but it is still a quite young coin, with a lot of special technology. So it takes more time to get other people involved. And as said before: If you think you can improve the current situation, do it. Right, and its not like we havent already attracted experienced developers in only 6 months. Someone posted leaked our bio page, check it out. We already have MIP working on the iPhone, Lich working on biblepay-central and Bhavani working on proposals, I don't get the logic that we arent creating a continuity plan. Luke and I are working on the biblepay trust for decentralizing the charities. Its really just nonsense fud coming from an individual who doesnt have the Holy Spirit. I think someone who mines with stolen electricity should be mining potcoin. |
|
|
|
Really nice day for BBP. Huge dump, c-cex almost closed, broken wallet and southxchange bbp wallet offline. What is coming next for BBP?  Its up to you to delete your own debug logs. The wallet isn't broken, its 'user error'  , and thesnat: try to have a more positive attitude as we are a Christian community (not a Satanic community). |
|
|
|
Small info: With the current problems, I stopped the payouts of purepool. I don't like the current instability, might create more problems. There will also be no new shares for a block per user shown in the user statistics. BUT nothing is lost, the block shares for the users will be calculated later, when it all is stable again Its just the instability on the single day when the superblocks cascade (or should I say, the following 24 hours). What happens is there are lots of contextual checkblock entries in the log (due to our BL that says one cannot mine without magnitude). All is well after that 24 hour period. All we need to do is delete the bloated log on that day : rm debug.log every few hours. Obviously I will be planning on fixing this for our June mandatory upgrade. It was a coincidence the pool went down the same day but its been reset. |
|
|
|
but wallet on ccex is down... so if it stays offline then all bbp stays there for 3 months...
I think it was down because of their internal maintenance; I skyped him this morning and he fixed it and I tested a withdraw today . |
|
|
|
Can you explain how pre-funding charities work? Have you committed to sponsoring a set number of children for Compassion and/or other charities? If so, does this number stay static until you get to a six month surplus? What happens after then? You try to maintain a six month surplus and that's the target each month? Or do you plan on changing goals like funding up to a year, or adding more children? I think this is good governance and mitigating the fluctuations in BBP & BTC prices.
What's the plan if BBP or BTC price tanks and your six month buffer starts to dwindle? What's the worse case scenario? People work for free, and make best effort to support poor children? Just trying to project what would have happened if we had a spike leading up to Jan 2018 and then a huge price crash for BTC.
We are about 60% prefunded (we are 850 orphan-months prepaid currently). For compassion, the current plan is to not sponsor new orphans until we reach 1800 orphan months prepaid, then we can use all available superblock charity funds to expand the compassion presence that particular month and then go back to focusing on 6 month prepayment. This buffer is rather large, so its not likely that a price shock will eat it up in one month. But as far as worst case scenario, we would go into a mode where we pay as many as possible and we would notify compassion that we would like to scale 10 orphans for example off of our roster (IE terminate the relationship with 10). This would be a very unfortunate circumstance and is not likely as we are in a growth phase (I see we gain a few CPIDs every day, etc). The absolute worst case scenario would be if bitcoin for example crashes to 1000, and is banned in 70 countries, and becomes a fad, then of course we would wind down our relationship monthly in tandem with our market cap. But lets stay positive and continue doing God's work, and he will bless our project for being good stewards. |
|
|
|
I see that coinmarketcap is reporting 50 million more coins than we have in the money supply:
gettxoutsetinfo
"total_amount": 670910023.49635832
Could someone see if it is the explorer doing this?
I noticed the money supply was accurate 3 days ago.
None of the block explorers, coinmarketcap or the console agree, Rob. Ok thanks, this looks like something Licht can take a look at reconciling sometime, and then the change can be propagated to Togos explorer. |
|
|
|
yeah, but if ccex will be closed for 3 months, then south or qiex will goes up. nobody will wait 3 months for opening ccex
...and I think this could also be a good thing. If both exchanges have such low overall volumes and BBP rises significantly, then chances are that at one point or the other it's gonna account for a high percentage of the overall volume on these exchanges and therefore gain more recognition. Of course we may see huge leaps (up AND down) in the price because of the low liquidity, but again this could help getting more people to look into the project.  This is not like last time c-cex closed registration. Back then, registered ppl could at least deposit and withdraw. Now nobody will be able to do that. This will force everyone to go to SouthXchange or QIEX. For me this is a death blow for C-Cex, I expect that when they come back from "holidays" the see everybody is out for good. And of course my suspicion is that another "unfortunate" event will happen and many people will see their wallets dissapear because of some weird hack. Biblepay is the best CPU coin I can find and I am going to quit crunching until the exchange situation gets more clarity. C-cex is our high volume exchange and I am not going to make the assumption that volume will shift over to the other exchanges. C-cex has a bunch of Indian traders. The chat is almost exclusively Indians. The highest volume coin on C-cex is an Indian coin called MCAP, so it is probably Indian traders who make up a lot of our marginal volume, trading BBP back and forth. I am not convinced they will follow over to the other exchanges but I would love to be proven wrong. I don't want to get in a position where I can't sell BBP to cover my expenses. This is a bummer, but I'll be hanging out and watching over the next few months. Like MIP said, there is a danger C-cex doesn't come back. It is not good to have had the problems with the XVG wallet that were apparently the fault of C-cex. C-cex lost their customers' coins, and then the refund policy was done as a buyback with C-cex making the market. Many, most or all of the people were not refunded their entire portion of their original lost account value, and now after doing this, C-cex decides to go on a 3 month vacation. This is too great of an uncertainty and poor business management to not have to manage risk accordingly. This is a good observation. Everyone should be vigilant in this situation: don't store more than you can afford to lose on an exchange in BBP or BTC (or fiat or crypto). Always make the assumption that one morning you will wake up and one of our exchanges will be gone and then there is no recourse as money lost in an exchange wallet is most likely non-recoverable. |
|
|
|
|
Show Posts
