My understanding is that ipfs is the groundwork for the dahf (hedge fund) which I thought was a variation of a retirement 401k type fund. I'm not sure. Or it could be one of Rob does whatever he wants projects. He's the lead dev so he wants/has that perogative.
You feel the road map features should be first priority?
As for news and updates, Rob has taken away edit rights on the wiki (at least myself and several others) so we can't update the information. Frankly, mediawiki kinda sucks to work with so I'm glad I don't have access.
There's biblepay.org (official) and third party efforts like purepool, biblepay-central , etc
You want more content on BiblePay.org? What about this forum, Reddit, Twitter, discord?
Please do not just make things up SunK, thats why our communication is bad- and posts end up getting deleted - and frankly, in a non Christian disagreement. Let's take a step back and forgive each other first. Next, let me explain what irks me: a person who "guesses" and states it as fact, on a public forum (this continually happens with your account and I rashly react by deleting the post). So jumping ahead to the wiki, I did not remove edit rights because I'm a dictator, I removed them because Slovakia defaced the front page. Hopefully you can understand that after someone defaces the actual investor info page, we need to control access. I have given edit to anyone who wants to make an intelligent edit Like Jaap and Togo. "Mediawiki sucks to work with"? Lets instead glorify the benefits that opensource software gives us. Lets use what we have until we are a $10 mil organization then we can vote on something that everyone likes, or maybe everyone does like wiki in general. I know I havent shared a lot of info regarding the DAHF vision. Frankly its because I put a lot of hours into the proof of concept, got it working, and the long e-mails from the focus group and SEC attorney are frankly so long and technical, it would make most people turn away from this project. I think at this point it is not going in the roadmap- lets keep it simple and build a stronger foundation without DAHF. Let's be positive - and frame questions that you BELIEVE are negatives as : Hey Rob, I THINK we have a problem with this, can we do this better. Then I reply and tell you if I agree or not- I would not say this if 80% of the time the other person doesn't understand that part of a feature exists because their solution isnt solving what they think. |
|
|
|
I saw a post on reddit about some changes (they seem positive) coming. If I could offer one piece of advice it would be to completely update the documentation and centralize it before making any more changes. This entire project has turned into spaghetti code. Features added, features removed, some info on bitcointalk, some on the bbp forum, some on the website, some on the wiki. The wiki is also worthless as there are no links to any pages. Its impossible for anyone to keep up with this coin without a significant time suck. And to find out where things stand it feels like I have to read 30 pages of old forum posts. Like it was sheer luck that I saw the thing about needing to research for R@H too. I have been doing strictly WCG.
It would be very nice to have some kind of future development plan on one centralized place. Yesterday I noticed bible_pay telling big number of c# commits going into version control and started looking what it will be. Spending more than 15 minutes I did not find information about it. Progress on https://www.biblepay.org/cryptoguru/#roadmap is not correct. IPFS is not mentioned in roadmap at all even though it is already ready to publish. There are only 2 projects in our source control that are c#: Stratis biblepayd, and the pool. The large commit was for the pool. I have been updating the roadmap and it currently reflects what our future vision is. DAHF is not in it at this time (as I mentioned - that is a concept, and it remains a concept while I work with the SEC attorney, it may never become a proof of concept for biblepay). IPFS is still a proof of concept- we are releasing IPFS into the next mandatory in a very limited way - it will be fully functional. Once it passes a beta test, we might slate it in the roadmap. Its much further ahead than DAHF. Imo, DAHF has fallen back from a 7 to a 1, and IPFS has gained from 1 to a 7 in liklihood to be on the roadmap. So the current roadmap is actually accurate. We are waiting for beta test results in different areas. |
|
|
|
** Resolution for World Community Grid Credit Handling **
The root cause of the WCG credits tallying as zero is that our sanctuaries are not handling the WCG daily credit export file properly. A hotfix has been programmed and tested.
1.1.5.6 has just been released. In order to fix the problem, we need Sancs to upgrade. (Users do not need to upgrade until the next mandatory release).
Sancs, please upgrade to the latest version.
EDIT: The pool superblock view report will be fixed within an hour; the problem can be fixed if the pools upgrade to the latest version. Purepool, I believe you will also need to upgrade to the latest version. BiblePay Pool will upgrade now.
EDIT2: Windows is building.
1.1.5.6 for Windows is released; upgrading the Pool and Sanctuary 1 now. Ok, the pool has been upgraded, now you can see the Reports | Superblock View report, and the WCG RAC should be correct. Please let me know if you see any missing WCG rac. As far as the next superblock payment, the payouts are based on the winning contract. Most likely the contract will be similar to yesterdays: Primarily Rosetta based. The quicker the sancs upgrade, the more likely that tomorrow's superblock will contain all of the WCG magnitude. |
|
|
|
** Resolution for World Community Grid Credit Handling **
The root cause of the WCG credits tallying as zero is that our sanctuaries are not handling the WCG daily credit export file properly. A hotfix has been programmed and tested.
1.1.5.6 has just been released. In order to fix the problem, we need Sancs to upgrade. (Users do not need to upgrade until the next mandatory release).
Sancs, please upgrade to the latest version.
EDIT: The pool superblock view report will be fixed within an hour; the problem can be fixed if the pools upgrade to the latest version. Purepool, I believe you will also need to upgrade to the latest version. BiblePay Pool will upgrade now.
EDIT2: Windows is building.
1.1.5.6 for Windows is released; upgrading the Pool and Sanctuary 1 now. |
|
|
|
|
** Resolution for World Community Grid Credit Handling **
The root cause of the WCG credits tallying as zero is that our sanctuaries are not handling the WCG daily credit export file properly. A hotfix has been programmed and tested.
1.1.5.6 has just been released. In order to fix the problem, we need Sancs to upgrade. (Users do not need to upgrade until the next mandatory release).
Sancs, please upgrade to the latest version.
EDIT: The pool superblock view report will be fixed within an hour; the problem can be fixed if the pools upgrade to the latest version. Purepool, I believe you will also need to upgrade to the latest version. BiblePay Pool will upgrade now.
EDIT2: Windows is building.
|
|
|
|
same here, wcgrac=0
no changes with setup so far, problem must be somewhere else
Alright - I see the problem- we are going into Disaster Recovery Mode to temporarily only honor Rosetta credits. Please standby. I will update with a resolution shortly. |
|
|
|
I e-mailed Jimmy Mellado, president of Compassion this morning with a new idea (proof-of-orphan-sponsorship). I went into details about how we could integrate Compassion into BiblePay, using the Compassion API (for multiple uses, one being governance receipt reimbursement, and one being mining).
I'm looking forward to conference calls with Compassions IT team.
Nice! Very curious about this plan. Will you give us an update on what you and April are doing with PR? I think Tom was directing this at Jaap; yes Jaap is handling that project. |
|
|
|
|
All-
Someone just made me aware the Pool superblock report is chopped off, and their internal WCG RAC is 0 but they do have UTXO level of 100%.
I started to take a look at this - and it appears there is a problem with the WCG export file.
I will make this a top priority and get an answer for everyone now.
Please hold off on using the Pools superblock view report for now - it is not accurate.
|
|
|
|
can ANYONE tell me WHY my WCG RAC is FU**ING ZERO AGAIN??? after one year, still same problems are occuring... "183b46bd8c5bd5ce00e5b4cf8b079704_RAC": 873.13, "183b46bd8c5bd5ce00e5b4cf8b079704_TEAM": 15044, "183b46bd8c5bd5ce00e5b4cf8b079704_WCGRAC": 0, "183b46bd8c5bd5ce00e5b4cf8b079704_TaskWeight": 100, "183b46bd8c5bd5ce00e5b4cf8b079704_UTXOWeight": 21479, "Total_RAC": 873.13, https://stats.free-dc.org/stats.php?page=userbycpid&cpid=183b46bd8c5bd5ce00e5b4cf8b079704i did ONE thing, added one rosetta computer... this fucked things up... i'm only loosing 30.000 BBP daily !!! Please remove the swear words. |
|
|
|
Delayed proof of work: In this scheme, 64 trusted nodes become notaries (think 64 of our sanctuaries). These are trusted to log and vote historical bitcoin blockhash consensus entries (IE known concrete historical non-forked blocks). These notaries then become witnesses to the current hashing algorithm modified by the historical bitcoin hashes (for gamecredits for example) giving you supposedly more secure sum of POW. So - its as trustful as your belief in centralizing trust to those 64 sancs. Its OK, but it could be argued that that ecosystem is less decentralized, less trustworthy (putting faith in the rich 64 nodes who everyone trusts) than a flat out POW system with a security addition (like our signed CPIDs). I'm far more excited to make a custom mining algorithm out of IPFS. I was thinking this morning, if we had IPFS "miners" - those with open API ports communicating in a trusted swarm, we could potentially charge BBP for outbound bytes, and make miners Pay BBP for inbound bytes, and modify the IPFS to be a new mining algorithm that helps enable the sharing of the biblepay hosted files. (To replace proof-of-work). So far its just a concept and thats what Im looking into next. |
|
|
|
Please. Need more help. {
"Command": "totalrac",
"Total RAC": 345.67,
"UTXO Target": 7604.740000000002,
"StakeBalance": 1000,
"Note": "You have less stake balance available than needed for the PODC UTXO Target. Coins must be more than 5 confirmations deep to count. See coin control.",
"Threshhold to receive 10% rewards (below this UTXO Amount rewards are lost)": 276.54,
"Stake Level Required For 10% Level": 283.45,
"Stake Level Required For 20% Level": 691.34,
"Stake Level Required For 30% Level": 1382.68,
"Stake Level Required For 40% Level": 2074.02,
"Stake Level Required For 50% Level": 2765.36,
"Stake Level Required For 60% Level": 3456.7,
"Stake Level Required For 70% Level": 4148.04,
"Stake Level Required For 80% Level": 4839.38,
"Stake Level Required For 90% Level": 5530.72,
"Stake Level Required For 100% Level": 6222.06,
"Total Team RAC": 7253723
"Command": "getboincinfo",
"CPID": "8207d91142045cb6d7a81b8e91d264a8",
"Address": "BHfGTogcn36yUY4VH5uEnd1ocT3oXWZnt7",
"CPIDS": "8207d91142045cb6d7a81b8e91d264a8;",
"CPID-Age (hours)": 427205,
"NextSuperblockHeight": 73400,
"NextSuperblockBudget": 1093468,
"8207d91142045cb6d7a81b8e91d264a8_ADDRESS": "BHfGTogcn36yUY4VH5uEnd1ocT3oXWZnt7",
"8207d91142045cb6d7a81b8e91d264a8_RAC": 345.67,
"8207d91142045cb6d7a81b8e91d264a8_TEAM": 15044,
"8207d91142045cb6d7a81b8e91d264a8_WCGRAC": 0,
"8207d91142045cb6d7a81b8e91d264a8_TaskWeight": 100,
"8207d91142045cb6d7a81b8e91d264a8_UTXOWeight": 1000,
"Total_RAC": 345.67,
"Total Payments (One Day)": 0,
"Total Payments (One Week)": 0,
"Total Budget (One Day)": 1093468,
"Total Budget (One Week)": 7654276,
"Superblock Count (One Week)": 8,
"Superblock Hit Count (One Week)": 8,
"Superblock List": "73195,72990,72785,72580,72375,72170,71965,71760",
"Last Superblock Height": 73195,
"Last Superblock Budget": 1093468,
"Last Superblock Payment": 0,
"Magnitude (One-Day)": 0,
"Magnitude (One-Week)": 0
So: on Rosetta site I have: Recent average credit = 345.67 on Wallet: Total_RAC": 345.67 on WCG site: Avg. Points Per Calendar Day = 21,518.00 on Wallet: WCGRAC = 0 Wat's wrong!? I wanna do WCG... ------------------ And second one: Please look at https://www.purepool.org/main/miner/B5CaFaFbgg2i8fqiMgorjXew28aNfW7tu4/I steel got error: Illegal_CPIDYou are closer! You now have 1000 bbp - you only need 350 to be in the 30% bracket. Now you need to send a UTXO. Try: exec podcupdate true If successful wait 6 confirms. Then do 'exec utxoreport cpid' and see if your utxo shows up. |
|
|
|
Since we're doing the contacts in BiblePay testnet with the ability to send payment via e-mail address. I wonder if we could also send by phone number. Then somehow add this to the Android and iOS wallet where you could send payment to someone else's phone number. It could also be a way to airdrop to people. They sign up for the newsletter and you airdrop them 1k BBP to their "e-mail". So they have to run BBP and add their contact detail to receive the e-mail? Not sure if you can receive BBP on the blockchain for an e-mail that isn't registered yet... I want to take a second to let everyone know that we care about their anonymity. First of all, we do not store any personal info in the chain (we store the contact records in IPFS), and for GDPR compliance we allow a user to delete the contact record (we update the fields with empty strings and save the new value with a deleted flag=1). Second, even with BOINC, we only store your public key and your CPID in the chain, we do not track or store any personal info. You may use a nickname in your boinc account if you wish. In that vein, Id want to veer away from any more features that makes biblepay look like we are trying to track people. However, from the perspective of Mobile Devices, and public churches, yes, I like your idea. I was going to say, we could make a general purpose field like 'usertext1' and allow them to store anything they want (or a phone #), but yes, it would be nice to send BBP from the actual mobile phone # that MIP grabs from the android device to another mobile user - goes hand in hand with the unbanked features. As far as the mobile android actually retrieving the IPFS record: its possible. So, yes, we could do it. Let's take a baby step first and see if MIP is willing to add a tithe button to the mobile app. That will exercise his ability to retrieve an IPFS record on the mobile and send Biblepay as a tithe to a recipient. Then you can add a github request to our mobile branch. If you want go ahead and add one for Tithing and send via phone number. |
|
|
|
I e-mailed Jimmy Mellado, president of Compassion this morning with a new idea (proof-of-orphan-sponsorship). I went into details about how we could integrate Compassion into BiblePay, using the Compassion API (for multiple uses, one being governance receipt reimbursement, and one being mining).
I'm looking forward to conference calls with Compassions IT team.
Nice! Very curious about this plan. All credit to Yeshua Hamashiach. God, please let us integrate for You. |
|
|
|
on WCG site: Avg. Points Per Calendar Day = 21,518.00
on Wallet: WCGRAC = 0
Same issue here from 3 days ago. I don't have any Rosetta Boinc from the time I installed wallet 1145 (19Aug2018) Starting Rosseta Boinc back two days ago, didn't help. Nothing changed in my system in the last days, except for: I registered to get rewards in NEUMANNIUM and Solaris. (for this I didn't changed my WCG and Rosseta web settings) Edit: Solaris is a mistake, I mean Sparc If your UTXO stake is 0%, the WCG rac = 0 in this wallet version. Could you run an 'exec utxoreport CPID' and verify you have UTXOs out there? Then your WCG RAC should display properly if you are above the 10% threshhold. |
|
|
|
LOL, wait til the chart updates with last nights commit in c#, it was a whale. |
|
|
|
|
I e-mailed Jimmy Mellado, president of Compassion this morning with a new idea (proof-of-orphan-sponsorship). I went into details about how we could integrate Compassion into BiblePay, using the Compassion API (for multiple uses, one being governance receipt reimbursement, and one being mining).
I'm looking forward to conference calls with Compassions IT team.
|
|
|
|
|
I received some replies from Mintnodes that raise the credibility somewhat, although I still want to say "INVEST AT YOUR OWN RISK - Dont send capital you cant afford to lose":
=-=-=-=-=-=-=-=
Rob,
Our system will create and teardown masternodes as needed, all of this is automated to keep costs down to maintain our $1/month/masternode fee.
Well Exchanges and Shared Masternodes are two different things, as you know we have to have coins stored somewhere in collateral amounts. We are always honest and transparent.
I don’t want to go into too much detail of our architecture as it is proprietary information that belongs to Mintnodes LLC, but the wallet coins are stored remotely away from the masternode servers. The coin wallets are on an isolated network from the internet. We use PCI compliance practices, as I have been the last 15 years.
Mintnodes was started by our family and only 2 people of our family have access to the coins.
I don’t know if it was you but someone from BBP was asking the same questions in our discord server.
Steve.
=-=-=-=-=-=-=
I see people have voted down Togo's proposal for this, but he did spend his personal BTC on this and did it out of the goodness of his heart. Imo we should vote yes for reimbursement.
|
|
|
|
You should do 'exec totalrac', see what utxo is required.
You can force one out with:
exec podcupdate true
See what that command says ? Then if it was successful, in 6 blocks , the exec utxoreport will reflect a UTXO.
Then you will be good on PODC rewards during the next Sanc Quorum - then superblock.
From these steps I don't understand clearly. Can You explain more?
23:52:39
exec totalrac
23:52:45
{
"Command": "totalrac",
"Total RAC": 345.67,
"UTXO Target": 7604.740000000002,
"StakeBalance": 0,
"Note": "You have less stake balance available than needed for the PODC UTXO Target. Coins must be more than 5 confirmations deep to count. See coin control.",
"Threshhold to receive 10% rewards (below this UTXO Amount rewards are lost)": 276.54,
"Stake Level Required For 10% Level": 283.45,
"Stake Level Required For 20% Level": 691.34,
"Stake Level Required For 30% Level": 1382.68,
"Stake Level Required For 40% Level": 2074.02,
"Stake Level Required For 50% Level": 2765.36,
"Stake Level Required For 60% Level": 3456.7,
"Stake Level Required For 70% Level": 4148.04,
"Stake Level Required For 80% Level": 4839.38,
"Stake Level Required For 90% Level": 5530.72,
"Stake Level Required For 100% Level": 6222.06,
"Total Team RAC": 7270675
}
23:59:25

exec podcupdate true
23:59:36

{
"Command": "podcupdate",
"PODCUpdate": "Unable to create PODC UTXO::Balance (0.00) less than target UTXO (7604.00)."
}
Does I need Balance of BBpay more then 0? and more then 7604 ? But how ? if mining PoW doesn't work. Faucet from pool doesn't work to.... I don't wanna by it from exchange( In our current state, Biblepay requires some BBP balance to be 'staked' in order to receive PODC rewards. For your cpid you would need 6225 BBP to be staked to get the full daily reward - but you can go as low as 300 bbp, if you want 10% rewards. Below 276, and rewards are lost. Yeah, you either need to get them from the exchange or from the faucet. The faucet should still give 1000. What faucet error do you get? Yeah, you cant heat mine bbp without a CPID with magnitude. The next version in 15 days does relax the rules for that, but lets not rely on that as its going to confuse everyone. |
|
|
|
Please install the BOINC gui (IE apt-get install boincmgr) and check your RAC on your local machine - see how high it is. See if 'exec getboincinfo' shows your cpid.
Its Windows, Cant find console in BOINC. But the Rosetta site and the Wallet show the same CPID. That's is command from Wallet debug (Wallet and BOINC on the same PC now) 22:30:28

exec getboincinfo
22:30:34

{
"Command": "getboincinfo",
"CPID": "8207d91142045cb6d7a81b8e91d264a8",
"Address": "BHfGTogcn36yUY4VH5uEnd1ocT3oXWZnt7",
"CPIDS": "8207d91142045cb6d7a81b8e91d264a8;",
"CPID-Age (hours)": 427195,
"NextSuperblockHeight": 73195,
"NextSuperblockBudget": 1093468,
"8207d91142045cb6d7a81b8e91d264a8_ADDRESS": "BHfGTogcn36yUY4VH5uEnd1ocT3oXWZnt7",
"8207d91142045cb6d7a81b8e91d264a8_RAC": 345.67,
"8207d91142045cb6d7a81b8e91d264a8_TEAM": 15044,
"8207d91142045cb6d7a81b8e91d264a8_WCGRAC": 0,
"8207d91142045cb6d7a81b8e91d264a8_TaskWeight": 0,
"8207d91142045cb6d7a81b8e91d264a8_UTXOWeight": 0,
"Total_RAC": 345.67,
"Total Payments (One Day)": 0,
"Total Payments (One Week)": 0,
"Total Budget (One Day)": 1093468,
"Total Budget (One Week)": 7654276,
"Superblock Count (One Week)": 8,
"Superblock Hit Count (One Week)": 8,
"Superblock List": "72990,72785,72580,72375,72170,71965,71760,71555",
"Last Superblock Height": 72990,
"Last Superblock Budget": 1093468,
"Last Superblock Payment": 0,
"Magnitude (One-Day)": 0,
"Magnitude (One-Week)": 0
}
This brings up a great point all... In the current version, we multiply the Sent UTXO Weight * World Community Grid RAC first (that explains why people are complaining they have 0 for WCG). So this will be fixed in the next mandatory. For now, the goal is to ensure you have some utxo weight. Then check your WCG RAC again. So looking at your cpid: exec utxoreport 8207d91142045cb6d7a81b8e91d264a8 You dont have any current UTXO... You should do 'exec totalrac', see what utxo is required. You can force one out with: exec podcupdate true See what that command says ? Then if it was successful, in 6 blocks , the exec utxoreport will reflect a UTXO. Then you will be good on PODC rewards during the next Sanc Quorum - then superblock. |
|
|
|
|
Show Posts
