I was under the impression, perhaps incorrectly, that an attacker could have 1 CPID to gain magnitude and use the rest of the machines as heat miners to enforce that attack to solve 1 block at 51% of the network hash rate. I wondered if solving that 1 block would cause the chain to fork and thus giving the attacker their way against the coin and allowing double spend. What you are saying is that greater than 3 blocks need to be solved consecutively with over 51% of network hash rate in order to even begin at starting a successful 51% attack? There is a website that has been published that is listing the cost of attempted 1 hour 51% attacks for various coins: http://crypto51.app I haven't tried to calculate the 1 hour cost myself, so I am still a little bit skeptical at some of the assumed costs for some of the coins are so low. For example, the 1 hour attack cost of Vertcoin is $700. What is unique about Biblepay is that Rob has come up with a much better solution to prevent 51% attacks. Staking to mine makes a possible attack more expensive (Even though a small stake would be required to heat mine, it is a good solution to require for other POW coins). The unique CPID requirement makes an attack more difficult. I am interested in more general solutions to preventing 51% attacks to make crypto safer and more sustainable. If all coins required a unique ID like a burned CPID, Nicehash could require a CPID tied to a user's account so that someone attempting a 51% attack through Nicehash would be stopped. The brute force hash attack (with one CPID) will not work. Because renting 51%*2500 PCs of hashpower will only let them solve 1 block with the single cpid. To solve blocks N+2 to N+7, they need distinct CPIDs (or there is not a valid solution). Thats why they would also need those rented machines to have associated distinct CPIDs with magnitude. Note that they are not causing the chain to fork. They are trying to become the dominant miner on the main chain and then fraudulently inject a double spend after solving X consecutive blocks. The entire attack fails if one of our good cpids solves Any block in between. Yes, the unique CPID idea with nicehash is true but this is also a classic tradeoff between anonymity and security. Most coins do not consider GUIDs or CPIDs because they feel the users are losing anonymity. We however needed it for cancer mining so we leverage it for security. And of course our users know they can use nicknames etc in boinc, so they really dont lose anonymity (except for stats tracking which is a benefit). |
|
|
|
I started running BOINC on an Android device a couple of days ago.
It shows up in Your Computers at my boinc.bakerlab.org account, user name zthomasz.
It has crunched some Rosetta tasks (Avg Credit 65, Total Credit 673) but it is not in the Rosetta Unbanked Report at pool.biblepay.org.
Is there anything I need to do to get it listed on at the pool?
First please ensure it is part of team Biblepay. Next, decide if you want it to share your existing CPID (IE if you have other PCs associated with your wallet and want to add the phone on to that existing cpid). If you do, just ensure the e-mail matches your other machines e-mail, and then all machines + this phone will tally to your controller wallet magnitude. If you are sure you want to make it an unbanked phone, with its own distinct CPID, then you can log into the pool, and click Account | Associate Unbanked Device. Once that is done you should show up in the unbanked report after ~ 6 confirms or so. |
|
|
|
Man, what's up with our POW difficulty right now? 26006 - and it's been over an hour since the last block as a result. Crazy.
I don't understand this obsession with PoW difficulty. Difficulty goes up and down to keep the average blocktime as close to 7 minutes as possible. Since network hashrate changes and time to produce an acceptable hash is not guaranteed, you will see fluctuation of blocktime and difficulty. Ideally, you want the smallest gap between min & max time between blocks but this not possible with proof-of-work algorithm. Well, I'm not sure I'd go with the word "obsession" - but let me explain why it is interesting. The sliding scale of difficulty to hit 7 minute blocks is obvious and uninteresting - however, you said it yourself, that the network hashrate changes. The comment is roughly equivalent to "wow, our network hashrate 2 hours ago must have been much much higher than now, because our difficulty is high and it has taken a long time to get a block as a result - meaning that the difficulty will again soon slide back down to adapt to the fact that our network hashrate has shrunk." What it does it tell us some things about who is mining when. If the network hash suddenly increases such that our difficulty triples for an hour or two and then goes back down, how is that not a conversation topic? Nobody who has that much hash power is doing this adhoc, which means we have the part-time attention of some very big players. I find that a worthy note and a good discussion point. I do NOT find "DUH, 7 minute blocks!" to be an interesting point, but I guess to each their own. If the network hash rate is suddenly increasing for a short time, someone could very well be attempting a 51% attack to try and attempt to induce the ability to double spend. Rob, what are the controls that make sure this doesn't happen? What prevents someone from registering a CPID with Rosetta and then spinning up as many heat miners as they can to try and gain 51% or more of the network hash rate? They don't have the incentive to heat mine for reward but they have an incentive to attack and double spend. I don't yet know as much about this as I should, but doesn't the chain have to fork for a 51% attack and an attempt at double spend (spending currency the attacker did not earn) to be successful? So at 51% of the hash rate the attacker has the ability to enforce their own version of the blockchain, which in their own version, they could give themselves as much coin as they wanted. Couldn't we use the masternodes as trusted nodes to check for forks in the chain or unauthorized changes in the chain to prevent a successful 51% attack? Can you explain the security we have against a 51% attack? Thanks, Rob. We have better 51% attack protection than bitcoin but we are cheaper to attack (being smaller). Bitcoin has the problem of concentrated asics owned by a small quantity of miners that could collude together to attack. We have the broad base of 2500 pc's, which are more likely to be decentralized. So that part is the run of the mill answer (IE pc based vs ASIC based). However what we have added that makes it a magnitude harder to attack us is we require a distinct CPID to solve each block, and the CPID must have magnitude. Every 4th block we clear the buffer and allow (the old CPID to start again). This means we effectively break the ability to solve consecutive blocks. Of course you could own more than one CPID with mag, but you would need to buy 51% of the CPID pool, and thats a lot of research, in order to add an effective attack vector on top of the one above (IE the classic 51%). So in our case it looks like a 51% attack would be : 51% of the CPIDs, with magnitude, running on 51% * 2500 PC's (heat mining portion) - heat mining PCs running boinc with at least 250 CPIDs (based on last superblock of 524 researchers) with magnitude. It would be an expensive attack. We also have DGW (dark gravity wave) which increases the diff during an attack. If the perpetrator were trying to issue a coinbase, they would need 100 confirms, which is pretty much impossible. I don't want to discuss this publically to give any more ideas to any large whales and fuel the fire with any chance of putting our coin at risk. |
|
|
|
I don't see a problem with 1.1.2.6, this looks to be on your end.
Classic IT response.. I'll sit back and watch if others encounter issues. edit2: Same message on testnet with a "clean" install and associated cpid. ... Let me check into this... I dont see a problem with 1.1.2.6, Im still mining after 24 hours. To diagnose this in prod, first type: exec datalist dcc;YYYY 365 Where YYYY equals the first 4 chars of your CPID. Paste the results here. Step 2: Type 'exec podcupdate' and paste the results here. I'm sure the other person who had the problem resolved itself after the prayers were memorized. The high cpu usage during 15 seconds after the GUI loads is just the prayers being memorized in the background. You should leave the machine on for at least 10 minutes of mining to see if the errors clear. |
|
|
|
I don't see a problem with 1.1.2.6, this looks to be on your end.
Classic IT response.. I'll sit back and watch if others encounter issues. edit2: Same message on testnet with a "clean" install and associated cpid. ... Let me check into this... |
|
|
|
I am not seeing the same exact problem, but I booted up 1.1.2.6 on my desktop, saw the same error, unable to sign cpid.
Then I did this:
sendtoaddress your_bbp_address 1
This flushed my wallet and did not throw an error.
Then I did setgenerate true 7
Then I did getmininginfo, and now I have solutions.
So Im heat mining now, please try that.
If anyone else has any issues with this, let us know so we can debug this.
Checking the pool, now my shares are counting without an error.
Followed the steps, seemed like it helped at first, but I'm still getting the error edit2: Nope.. still giving me the error I've got a few machines presenting this, so I can do some additional testing if it helps. feel free to e-mail me if it's easier to chat there .. (not sure of any live chat's your in.) I don't see a problem with 1.1.2.6, this looks to be on your end. |
|
|
|
Rob:
My heat-miners don't appear to work with the .6 release
"poolinfo1": "Unable to sign CPID; Unable to sign CPID; Unable to sign CPID; Unable to sign CPID; ",
"poolinfo2": "Submitting Solution 06-12-2018 23:32:01; Failed to sign CPID Signature (Address does not refer to key); Failed to sign CPID Signature (Address does not refer to key); Submitting Solution 06-12-2018 23:31:39; ",
"poolinfo3": ""
I've even tried a full unlock and i'm still seeing it
edit: this is on mainnet
I am not seeing the same exact problem, but I booted up 1.1.2.6 on my desktop, saw the same error, unable to sign cpid. Then I did this: sendtoaddress your_bbp_address 1 This flushed my wallet and did not throw an error. Then I did setgenerate true 7 Then I did getmininginfo, and now I have solutions. So Im heat mining now, please try that. If anyone else has any issues with this, let us know so we can debug this. Checking the pool, now my shares are counting without an error. |
|
|
|
|
Just a friendly reminder for those adding scriptures using our "prayer" feature in the wallet (IE Send Money, click Prayers checkbox, type a message into the prayer field):
The feature is really intended for prayers (IE please pray for my sick mother, she has cancer) etc.
I realize by quoting the scripture you are trying to help non believers and I understand that, so I am not coming down with this in a negative way.
Im just suggesting that we keep the field open for prayers. If you want to quote a scripture, try to add something in a way to make it edifying like: you will burn in hell for Jesus said: this, so I pray that this message reaches you, Heathens.
The other thing I wanted to mention is someone pasted a really long scripture, like 1000 chars and its kind of embarassing the wallet cut it off. So Ill make a bullet point to fix that display in the wallet.
|
|
|
|
I think you are missing the point on the Apple branded iOS device ARM chips. The projects don't support them because BOINC is not supported on iOS. So, since BOINC cannot run on iOS at all right now due to their restrictions.... NO projects will compile their app to run on a non-existent option. They would have to code their own client and hard code the executable into it. Once there is a platform, projects will adopt as necessary. Berkeley didn't even bother making BOINC on Android until the community released nativeBOINC. Then once that was in the wild and a few projects had apps for it, Berkeley went ahead and release a compatible version. However, iOS/Apple has been discussed many of times. It all comes down to Apple not allowing the application (BOINC or any other) to download executables from external sources and thus no version of BOINC in the itunes store.
I'm not missing the point. Re-read my post. I'll PM you. |
|
|
|
|
From Compassion:
Thank you for your continued love and support of children living in extreme poverty. We are so thankful for your partnership.
You probably noticed your latest letters from Maria Lorena Sousa Silva, Ariana Mabel Guerrero Chinchay, Keyla Jhasmin Rodriguez Perez, Yerson Isaac Cruz Mejia, Fabricio Gadiel Arevalo Tamay, Anner Jafet Amador Pereira, Yaret Isaac Sanches Torres, weren't quite right. Recent glitches in our child letter system sent out letters with missing, incorrect or incomplete translations, and as we tried to fix the errors, some letters were sent multiple times. We are so sorry for the confusion this may have caused you. The issue has been resolved and you should receive another copy of Maria Lorena's, Ariana Mabel's, Keyla Jhasmin's, Yerson Isaac's, Fabricio Gadiel's, Anner Jafet's, Yaret Isaac's, Jeferson Enrique's, Andy's, Aaebersa's, Kimberli Noemi's, Jamesly's, Elfrans', Habtamu letters with the correct translation soon.
|
|
|
|
Hi everyone, I recently got in contact with a representative from Compassion and confirmed that Biblepay is indeed sponsoring the number of children it says it is. Below is the E-mail communication: Hi Michael, Sorry I was traveling for work this week and am now catching up on emails. As of Tuesday’s report we show 302 sponsored children in the BiblePay record. Rob says he shows 306. It could be that these 4 graduated recently, moved, and are being replaced with new children in the program as we speak. BiblePay has pre-paid for its kids many months in advance as well. Warmly, Ginger Here is Ginger's LinkedIn: https://www.linkedin.com/in/ginger-langehennig-4b31981b/Thanks T-Mike, this goes a long way towards Bible Pay's long term credibility. Slovakia I guess its time for an apology and a fresh start here. And maybe you can also pray that you receive the Holy Spirit at the same time and its a win for all of us. On a side note, I was trying to find out how we are off by 4, and it turns out every so often, roughly every 45 days or so, we receive a pop up notice (when we are paying the bill) that says something like "This orphan has moved out of the region" or "This orphan has been met by a family and they adopted him" (Im not exact in these quotes so please excuse me), well anyway, one of the options is you have to immediately choose to replace the child with a new child or lose the child! So Im sure I only did this correctly twice, so that explains how we can be slightly off. But I do have record of the last change and the action (primarily because the rep called me this time). Note I want this to be exact so I am working with ciqueue to fix it (the problem was the notification dissapears and I didnt have time to write down the ones we lost at that particular time). So in this last case, we have replaced Jefferson with Orphanid='08113194',name='Julio Cesar Herrara Valle'. So in this case our count didnt change, but I think in the other 3 cases, the count did decline by one. Either way the money that was spent was spent on the child beforehand, and I assume Compassion keeps it if they are prepaid. So this is a high priority question for me to ask Ginger. What happens to the accumulated money if we lose a child. I'll check this out now via e-mail. |
|
|
|
Apple announced changes to its policies to disallow mining on their mobile devices inside an app.
While this is largely targeted against scammy devs that build background mining into their apps, this clause concerned me:
3.1.5 (b) (ii) Mining: Apps may not mine for cryptocurrencies unless the processing is performed off device (e.g. cloud-based mining).
Google might take a very similar stance; if this is the direction things are moving, how do we see this affecting our goal of allowing unbanked mining on phones for people in remote areas without computers? It would be a real shame to lose that feature.
In our case from the apple standpoint, I think we would be OK, because BOINC does the research (and that activity should be construed as research not mining) but either way, the mother process BOINC, starts the threads for the research, while MIP's mobile wallet acts as a block acceptor and wallet. But the main show stopper with running boinc on the iphone is no project supports the proprietary apple processor so boinc only works on the mac currently. However this scenario could come up on the samsung galaxy, and we have a couple beta testers running biblepay-android and boinc currently on that device although I realize google doesnt have the clause yet. Actually, what is preventing BOINC on iOS is that they (Apple) do not allow the software do download executables from outside sources and run them. Otherwise there would have been an iOS version years ago. Basically, BOINC is in a similar boat as mining software.... I cannot really tell you how to do it as I'm not that fluent in the workings of crypto when looking under the hood. However, I would strongly encourage the devs to really try to lock down ways to mitigate cheaters better than Gridcoin has done. Collatz had to completely rebuild their site/servers/etc... because at least one Gridcoin user was cheating on a large scale under one of their pools. https://boinc.thesonntags.com/collatz/forum_thread.php?id=15#190The responses from the Gridcoin team did not sit well with the community as it basically came down to telling the community to fix their projects and to not tell Gridcoin how to run theirs. Science was indeed affected and has to be re-ran. This event was the straw that broke the camels back and essentially caused Gridcoin to be banned from the Annual Pentathlon which is the largest competition in the BOINC world amongst teams. Gridcoin users basically had coin stolen from them because of the cheater getting rewarded. I do not know if they ever resolved any of it as I don't follow their threads. Collatz lost the old forums that had a lot of the details in them. And it appears that a possible cheater has appeared yet again at another BOINC project - http://gene.disi.unitn.it/test/forum_thread.php?id=216#1325On a positive note, have you guys considered possibly adding GPUGrid to your list of projects? http://www.gpugrid.net/Thanks for the post and the links. So from what I can see, in both instances of the cheating that went on in those projects in that community, the user took advantage of an attack vector in which a vulnerability existed on the specific boinc project's server side, in the validation process, which made it possible to cheat on the actual result submission (IE it fooled the server into accepting the result of the workunit). Another words they studied the traffic that is posted by boinc that allows the work unit to be solved and falsified it. Note that there is no example of cheating outside of those few projects. (Thats partially why we picked Rosetta originally, it was partially discussed in the swongle discussions when we were in testnet with cancer mining- Part of the due diligence was to find a project that would be extremely hard if not impossible to cheat. This is because if you look at the manual from Rosetta commons, the work you are doing is so complicated (it requires a 3mb database on the client side to refer to), with 300 scientists on the back end, I don't think its possible to falsify a low energy 'result' without doing more effort than the client does to compute the low energy result. Also in both cases of the cheating note that the gridcoin user diluted their own project compensation - another words a report could have been written that showed a discrepency in task-turnaround/cobblestone-work, picking up the bad user. In that case if that happened here we would have to disable the project and regroup. As far as adding other projects, I feel we should stay focused with what we have now - these projects are related to our healing aspect (we picked Rosetta because it was based on potentially curing cancer), and WCG with their AIDS research. Although I'm interested in using clock cycles for the benefit of humanity, I'm not interested in expanding our mining side into a volunteer computing platform, primarily because I would rather support a high quality project and maintain the healing aspect or facet of biblepay. We have a lot of things to do on the roadmap, and one behind the scenes is investigating partners in the financial sector that also have some options for us in replacing proof of work with other cool cutting edge ideas (like analyzing financial markets etc). I don't know if you looked up GPUGrid or not, but they seem to be in line with what you are asking. http://www.gpugrid.net/science.phpCancer, HIV/AIDS, Neural Disorders, and Methods (pushing boundaries within their fields). They happen to also utilize GPU's (given their name) though they are doing some tests with CPU's too. They do have times where they don't have enough work for everyone, but it would be a good compliment for those wishing to utilize GPU's for something other than mining. Currently only nVidia cards are used. I understand not wanting to delve too quickly, but perhaps keep it on your radar. Thanks for the opinions, but it's a bigger problem for apples flavor of arm processor to run any of the project executables (than for the phone to run boinc). We are CPU only, so naturally suggesting gpugrid goes against the spirit of this coin. Our two supported projects are RAH and WCG. |
|
|
|
I would be pushing to be late on the mandatory for June and wait for it - if it were not for our June 26th cascading superblock bug that gives us a black eye.
Anyway there is also the possibility that we release the token as a leisure - because exchanges don't need the token. I'm focusing on this plan for now. In this way we might be able to have our mandatory before the superblock bug hits, but it's already the 12th, and we need to test for a couple weeks and also give the exchanges 10 days notice to upgrade, so we might not make it anyway. Let's see how testnet goes.
The exchange is not a masternode, do they really need the DCC info to be correct? I suppose the concern would be their client rejecting the rules and forking? I said in the prior post the token could be done as a leisure. So yes, the token is not part of a mandatory upgrade. The reason the token is important for scheduling is the mandatory upgrade is a point where the network comes together with consistent rules. So it is a consideration to release the token if possible, if for example we hear from IBM a timeline on the release. At this point we don't even know if the download business logic is changing, so lets wait to hear from IBM. |
|
|
|
** WCG PODC UPDATE **
We are still waiting for the DPA to be re-written to be more volunteer computing specific.
Robert,
World Community Grid program manager, Juan Hindo, has posted a DPA update in the forums. Here it is the post as well:
Hi Everyone,
Wanted to give you a quick update and a bit of background on the status of our Data Processing Agreement (DPA), which will allow people who agree to it to access World Community Grid data exports, which were previously available before GDPR came into effect.
As many of you are aware, we've been working with lawyers to come up with an agreement that will serve the wishes of volunteers who use the data exports, while ensuring that we are GDPR-compliant, as defined by IBM. We did receive the agreement drafted by lawyers specifically for World Community Grid. But since IBM is a commercial entity that focuses on selling technology solutions, we felt that the agreement drafted for World Community Grid wasn't sufficiently geared towards volunteers. The World Community Grid team feels strongly that, in the long run, it's better for us to continue to work with the legal team to push for an agreement that we believe will meet volunteers' needs as well as IBM's needs, rather than give volunteers an agreement that is more geared towards commercial engagements and is not as relevant to a philanthropic initiative.
Sincere thanks to everyone for their patience during this process. We will use this thread to provide updates.
Many thanks,
Juan
Do you think you're gonna try to wait for that to be finalised before pushing the mandatory this month? or are you gonna make the changes before that and just insert the token id via spork later? I would be pushing to be late on the mandatory for June and wait for it - if it were not for our June 26th cascading superblock bug that gives us a black eye. Anyway there is also the possibility that we release the token as a leisure - because exchanges don't need the token. I'm focusing on this plan for now. In this way we might be able to have our mandatory before the superblock bug hits, but it's already the 12th, and we need to test for a couple weeks and also give the exchanges 10 days notice to upgrade, so we might not make it anyway. Let's see how testnet goes. |
|
|
|
I cannot really tell you how to do it as I'm not that fluent in the workings of crypto when looking under the hood. However, I would strongly encourage the devs to really try to lock down ways to mitigate cheaters better than Gridcoin has done. Collatz had to completely rebuild their site/servers/etc... because at least one Gridcoin user was cheating on a large scale under one of their pools. https://boinc.thesonntags.com/collatz/forum_thread.php?id=15#190The responses from the Gridcoin team did not sit well with the community as it basically came down to telling the community to fix their projects and to not tell Gridcoin how to run theirs. Science was indeed affected and has to be re-ran. This event was the straw that broke the camels back and essentially caused Gridcoin to be banned from the Annual Pentathlon which is the largest competition in the BOINC world amongst teams. Gridcoin users basically had coin stolen from them because of the cheater getting rewarded. I do not know if they ever resolved any of it as I don't follow their threads. Collatz lost the old forums that had a lot of the details in them. And it appears that a possible cheater has appeared yet again at another BOINC project - http://gene.disi.unitn.it/test/forum_thread.php?id=216#1325On a positive note, have you guys considered possibly adding GPUGrid to your list of projects? http://www.gpugrid.net/Thanks for the post and the links. So from what I can see, in both instances of the cheating that went on in those projects in that community, the user took advantage of an attack vector in which a vulnerability existed on the specific boinc project's server side, in the validation process, which made it possible to cheat on the actual result submission (IE it fooled the server into accepting the result of the workunit). Another words they studied the traffic that is posted by boinc that allows the work unit to be solved and falsified it. Note that there is no example of cheating outside of those few projects. (Thats partially why we picked Rosetta originally, it was partially discussed in the swongle discussions when we were in testnet with cancer mining- Part of the due diligence was to find a project that would be extremely hard if not impossible to cheat. This is because if you look at the manual from Rosetta commons, the work you are doing is so complicated (it requires a 3mb database on the client side to refer to), with 300 scientists on the back end, I don't think its possible to falsify a low energy 'result' without doing more effort than the client does to compute the low energy result. Also in both cases of the cheating note that the gridcoin user diluted their own project compensation - another words a report could have been written that showed a discrepency in task-turnaround/cobblestone-work, picking up the bad user. In that case if that happened here we would have to disable the project and regroup. As far as adding other projects, I feel we should stay focused with what we have now - these projects are related to our healing aspect (we picked Rosetta because it was based on potentially curing cancer), and WCG with their AIDS research. Although I'm interested in using clock cycles for the benefit of humanity, I'm not interested in expanding our mining side into a volunteer computing platform, primarily because I would rather support a high quality project and maintain the healing aspect or facet of biblepay. We have a lot of things to do on the roadmap, and one behind the scenes is investigating partners in the financial sector that also have some options for us in replacing proof of work with other cool cutting edge ideas (like analyzing financial markets etc). |
|
|
|
Apple announced changes to its policies to disallow mining on their mobile devices inside an app.
While this is largely targeted against scammy devs that build background mining into their apps, this clause concerned me:
3.1.5 (b) (ii) Mining: Apps may not mine for cryptocurrencies unless the processing is performed off device (e.g. cloud-based mining).
Google might take a very similar stance; if this is the direction things are moving, how do we see this affecting our goal of allowing unbanked mining on phones for people in remote areas without computers? It would be a real shame to lose that feature.
In our case from the apple standpoint, I think we would be OK, because BOINC does the research (and that activity should be construed as research not mining) but either way, the mother process BOINC, starts the threads for the research, while MIP's mobile wallet acts as a block acceptor and wallet. But the main show stopper with running boinc on the iphone is no project supports the proprietary apple processor so boinc only works on the mac currently. However this scenario could come up on the samsung galaxy, and we have a couple beta testers running biblepay-android and boinc currently on that device although I realize google doesnt have the clause yet. |
|
|
|
|
** WCG PODC UPDATE **
We are still waiting for the DPA to be re-written to be more volunteer computing specific.
Robert,
World Community Grid program manager, Juan Hindo, has posted a DPA update in the forums. Here it is the post as well:
Hi Everyone,
Wanted to give you a quick update and a bit of background on the status of our Data Processing Agreement (DPA), which will allow people who agree to it to access World Community Grid data exports, which were previously available before GDPR came into effect.
As many of you are aware, we've been working with lawyers to come up with an agreement that will serve the wishes of volunteers who use the data exports, while ensuring that we are GDPR-compliant, as defined by IBM. We did receive the agreement drafted by lawyers specifically for World Community Grid. But since IBM is a commercial entity that focuses on selling technology solutions, we felt that the agreement drafted for World Community Grid wasn't sufficiently geared towards volunteers. The World Community Grid team feels strongly that, in the long run, it's better for us to continue to work with the legal team to push for an agreement that we believe will meet volunteers' needs as well as IBM's needs, rather than give volunteers an agreement that is more geared towards commercial engagements and is not as relevant to a philanthropic initiative.
Sincere thanks to everyone for their patience during this process. We will use this thread to provide updates.
Many thanks,
Juan
|
|
|
|
Hello guys......any price predictions during the next 2 months or long term on biblepay? Any new exchanges coming? I think thats the only thing holding this great looking project at such a low price right now.
We are supposed to be listed on CryptoBridge in one month, Luke has a full report of more detailed exchange info, We are close to being listed on NEXTExchange, (our votes hit the threshhold). We have a hard offer to be listed on coinexchange.io for 2 BTC. As far as price, I can't really comment as that could be a conflict of interest but we are deflationary (by 19.5% per year) so please see the average coin appreciation since inception and see if it has grown by ~ that amount etc, that may be a good starting point. We have been keeping up with the roadmap, so the future looks bright for the orphans. |
|
|
|
Side project for a zealous taker:
I receive questions from various partners via e-mail about 'What is the biblepay governance system and what are proposals, budgets and how do i submit a proposal'. I respond with various links that we have established, mostly to the credit of Togo. Although I think we have good coverage on how to add a proposal and what a proposal is I believe our documentation is lacking on 'What is the governance system, and what are the details of the proposals'. I found this from Dash: https://docs.dash.org/en/latest/governance/understanding.htmlAnd although this is excellent, and I want to give credit to Dash, I feel we should have our own version on our wiki page to refer them to. So I am wondering if someone wants to paraphrase this content, use biblepay screenshots, and of course give all the credit to dash in various places (IE - This was originally created by Dash) and full credit in the footer. In this way we will have a more professional and consolidated reference to hand out to our partners.
|
|
|
|
|
Show Posts
