Addition of cryptocurrency address/account fields to profile?

Yo,

I've added ~35 cryptocurrency fields to the profile which doesn't interfere with established SQL tables however does inflate the profile/gz stat extracts, how plausible would it be to merge this into master?

Would it be more likely to be accepted if it was hidden away within its own page rather than visible within the profile? Or if a seperate stats extract (xml.gz) file would be more appropriate?

The justification for the introduction of cryptocurrency fields is that it may help enable an absolute proof of CPID ownership when registering an account for earning rewards on Gridcoin (with the team req removed) and/or on future BOINC cryptocurrencies.

Relevant repo: https://github.com/grctest/project-rain-site Location of changes: https://github.com/grctest/project-rain-site/tree/master/ProjectRain_Docker/images/makeproject/preCompileReplace Raised this issue within the 'For the betterment of BOINC' thread.

Best regards, CM.

Old screenshots (don't have the latest version running at the very moment, sorry):

The following screenshots show the old project-rain version, the pull request version auto-hides the fields when blank (so as to not immediately spam the profile view with crypto links).

User profile (self-view)

Browsing another user's profile

Example user xml

<?xml version="1.0" encoding="ISO-8859-1" ?>
<user>
    <id>2</id>
    <cpid></cpid>
    <create_time>1497573052</create_time>
    <name>derp</name>
    <country>United Kingdom</country>
    <bitshares>123</bitshares>
    <steem></steem>
    <gridcoin></gridcoin>
    <ethereum></ethereum>
    <ethereum_classic></ethereum_classic>    
    <golem></golem>
    <nxt></nxt>
    <ardor></ardor>
    <hyperledger_sawtooth_lake></hyperledger_sawtooth_lake>
    <hyperledger_fabric></hyperledger_fabric>
    <hyperledger_misc></hyperledger_misc>
    <waves></waves>
    <peershares></peershares>
    <omnilayer></omnilayer>
    <counterparty></counterparty>
    <peerplays></peerplays>
    <storj></storj>
    <nem></nem>
    <ibm_bluemix_blockchain></ibm_bluemix_blockchain>
    <coloredcoins></coloredcoins>
    <heat_ledger></heat_ledger>
    <antshares></antshares>
    <lisk></lisk>
    <decent></decent>
    <synereo></synereo>
    <lbry></lbry>
    <wings></wings>
    <hong></hong>
    <boardroom></boardroom>
    <expanse></expanse>
    <akasha></akasha>
    <cosmos></cosmos>
    <metaverse></metaverse>
    <zcash></zcash>
    <stratis></stratis>
    <echo></echo>
    <tox></tox>
    <retroshare></retroshare>
    <wickr></wickr>
    <ring></ring>
    <pgp></pgp>
    <total_credit>0</total_credit>
    <expavg_credit>0</expavg_credit>
    <expavg_time>1497573052</expavg_time>
    <teamid>0</teamid>
    <url></url>
    <has_profile>0</has_profile>
</user>

I followed the discussion within the gridcoin community a bit. So I have an idea of what you want to do. I don't think adding a field for every current cryptocurrency into BOINC in this way is the best solution. This has the potential of scarring away funding agencies for example. So we need to be a bit more subtle to merge the needs of the gridcoin community (as an example for the whole cryptocurrency community) into BOINC while also thinking about the needs of other communities that contribute to BOINC.

I currently don't have the time to delve deeper into a discussion on how to solve this. Maybe after the BOINC workshop in Paris in early September. My idea to solve your problem of verifying CPID ownership would be to add OpenID or OAuth2 based authentication to BOINC projects. Those are general protocols that can be used for other scenarios too. The project would be the authentication provider, the account manager would be the service and the user can authorize the service to access parts of his account on the project without giving away his authenticator or password. From the discussion I've seen these seem to be your main concerns. We could try to simplify that but I would really like to see a standardized solution.

As I said I would be happy to discus this some more after the workshop.

I have to second Christian's comments here (he beat me to the response). The BOINC system should not have code in it that makes it aware of specific external systems that want to verify users and their contribution. Cryptocurrency are not the first use of this type of external integration and they definitely won't be the last.

OAuth 2.0 is designed for exactly this type of integration and verification. It is also a standard which means that it is much more easily supported then a custom implementation. I would strongly encourage you to take a look at how that could be implemented within BOINC to meet your needs.

I followed the discussion within the gridcoin community a bit. So I have an idea of what you want to do. I don't think adding a field for every current cryptocurrency into BOINC in this way is the best solution. This has the potential of scarring away funding agencies for example.

I agree that the referenced project-rain merge request is a bit overboard (35+ fields) for a default BOINC server, especially given that many non-profit/university BOINC projects may be financially incompatible with cryptocurrencies.

This proposal wasn't purely for the Gridcoin community/network though, I believe that by introducing additional scrapable user-data fields we will open the doors to many new cryptocurrency projects exploring the concept of Proof of Research. Many crypto networks (Such as: Bitshares, Neo, Waves, Ethereum, NXT) offer user-issued-asset functionality, meaning that any BOINC team could issue their own token to their team members as a reward without requiring programming experience, by introducing such user-data fields the competitive edge (rewarding BOINC users) for the Gridcoin network is nerfed.

Regarding funding, some distributed ("decentralized") computing platform projects (GOLEM, SONM, iEX) have raised tens-hundreds of millions of dollars based on a fancy website and a whitepaper (not much more than grand promises & potential vaporware) whilst the BOINC network has been in a production state for coming on 2 decades now and has a large established userbase. Whilst the NSF may have thrown David Anderson a bit of funding for his 'TBA' standalone BOINC client project they are not funding the entirety of BOINC's development (nor have they been for years now); the introduction of crypto fields opens the doors to new avenues of funding (imagine several BOINC projects performing ICOs then contributing funding towards BOINC development for example).

There is also the matter of user retention, estimates for active userbase is between 250k-500k (depending on where you look) where as there have been more than 4 million registered users in the past - that's less than 10% of registered users still crunching. Everyone's got an old computer gathering dust in their closet somewhere, many would be motivated to disregard rising electricity bills (consequence of 24/7/365 competitive crunching) and continue crunching if their work was being rewarded by many crypto projects, not just the one (merge-crunching, similar to mergemining in POW cryptocurrencies).

So we need to be a bit more subtle to merge the needs of the gridcoin community (as an example for the whole cryptocurrency community) into BOINC while also thinking about the needs of other communities that contribute to BOINC.

Ideas to improve the subtlety of cryptocurrency integration:

Create an additional extract so that the user.xml.gz files aren't massively inflated.
Possibly making the implementation of project-rain more modular - Currently you need to fork repo, apply the changes then begin maintaining said fork to inherit core BOINC code changes.
When editing the crypto fields in the profile, rather than displaying all empty crypto fields use a dropdown & add/remove row buttons.
If all cryptocurrency references are off the table, then perhaps a single custom user data field would be more appropriate? Strict limits to prevent hacker abuse could be applied.

My idea to solve your problem of verifying CPID ownership would be to add OpenID or OAuth2 based authentication to BOINC projects. Those are general protocols that can be used for other scenarios too. The project would be the authentication provider, the account manager would be the service and the user can authorize the service to access parts of his account on the project without giving away his authenticator or password. From the discussion I've seen these seem to be your main concerns. We could try to simplify that but I would really like to see a standardized solution.

Would such oauth based auth enable 3rd party verification of account ownership?

E.g. If we were to verify an user's individual BOINC project account ownership via OpenID/OAuth2 when creating a CPID registration transaction, could a few thousand Gridcoin (or other crypto project) clients verifying the transactions and creating the bblocks also perform this check?

With the proposed address/user-data fields, all clients could easily scrape the address/account data from the compatible BOINC project servers like we do for the user.xml.gz data.

Likewise, these fields aren't solely for Gridcoin's use - an user could scrape every user's supplied bitcoin address and split 1 BTC across everyone (raining a crypto token across many users as a form of charity) or a new project may sharedrop a portion of their token supply onto the BOINC userbase for both historical (all-time RAC) computation and active RAC to invest in a potential large userbase with proportional computing power at their disposal.

An user who wanted to share 1 BTC (or any other token) would be hindered by having to require an oauth verification phase instead of just acquiring a list of <cpid,address,activeRAC,historicalRAC> for all projects via a simple website scraping script.

As I said I would be happy to discus this some more after the workshop.

Sounds like a plan to me! Sorry this reply took more than 2 weeks, looking forwards to the workshop!

OAuth2 has been designed to address exactly this type of situation. If you have ever enabled some application to have access to your twitter, facebook or google account information, then you have seen OAuth2 in action (or a very similar protocol). Here is an overview: https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

If this mechanism was available within BOINC already, then you would simply ask a BOINC project to set up a application for whatever entity you wanted. On the site of the application, you are then able to have a user login and then click a button to authorize the application to request permission to credit information for that users information on the BOINC project. The OAuth2 protocal details the flows for the user logs into the BOINC project and authorizes the application as well how the account on the application side is linked to to the account on the BOINC project side. After this occurs the application now has a token that allows them to fetch that users information at anytime. You could use this just once to get their CPID and store it on the application side and then parse the existing user export.

The important thing about this solution is that the BOINC makes one set of changes that can now handle many different types of integrations scenarios without having to know the details of each one. This is a much better architectural pattern than having BOINC know all possible external integrations within its code base.

@ChristianBeer wrote: My idea to solve your problem of verifying CPID ownership would be to add OpenID or OAuth2 based authentication to BOINC projects. Those are general protocols that can be used for other scenarios too. The project would be the authentication provider, the account manager would be the service and the user can authorize the service to access parts of his account on the project without giving away his authenticator or password. From the discussion I've seen these seem to be your main concerns.

Gaining limited access to an user's account isn't a current problem/concern for Gridcoin, the issue is that no 3rd party data (user data) can be appropriately/professionally stored within the BOINC profile in a manner which can easily be scraped by thousands of gridcoin clients (performing verification of CPID ownership legitimacy & reward eligibility).

OpenID/OAuth2 would indeed be great for automating the storage of 3rd party data (rather than having users manually place a public key in a field), however without a designated field for storing such data I don't see the benefit.

When an user registers for Gridcoin, they advertise a beacon which is a CPID registration transaction. The user's client locally checks that the user has logged into the account (w/ the boinc manager) and that the email provided (in their conf file) formulates the CPID. When such a beacon expires (every 6 months), it's possible for network replay attacks (using the last beacon registration data to make the next beacon) in which I could steal your registration (and begin earning your rewards). The resolution to such an attack is to either manually change your CPID (bad for external statistics sites & for internal reward tracking, and would likely cause CPID merging issues) or for an user with centralized control over the beacon registration system to delete the attacker's stolen beacon (inappropriate in a decentralized network).

We (potentially thousands of clients) currently gather the required data from the user.xml.gz files (every 24hrs); if we were to gather the required information (RAC, TotalCredit, etc) using Oauth2 on an individual user basis then we would likely cause a DDOS of the less powerful BOINC servers (say 50k clients in the future each querying 50k users on a daily basis = 2.5m queries instead of 50k gz downloads).

@TheAspens wrote: The BOINC system should not have code in it that makes it aware of specific external systems that want to verify users and their contribution.

My revised approach (WIP Repo) is a significantly reduced (more subtle & better documented) version of the original pull request & aims to not specify any external system by name, instead a single "user data" field is proposed.

All references to the 35+ cryptocurrency addresses/accounts (admittedley overkill) and related terminology will be removed (not completed yet), in adherence with the PMC's policy regarding "no code directly related to virtual currencies".

Ideally, the new field would be used in a space-delimited manner, (ie " external_system1:key1 external_system2:key2 ") so that the user could specify more than once item for external scraping.

With regards to the (accidental by design) DDOS of BOINC servers, we could further increase the sublty of this proposed additional field & decrease bandwidth utilization by the Gridcoin network if we were to create a new export file such as the following in the '/sched/db_dump.cpp' file:

void write_rain(RAIN& rain, USER& user, FILE* f, bool /*detail*/) {
    char buf[1024];
    char cpid[MD5_LEN];
    safe_strcpy(buf, user.cross_project_id);
    safe_strcat(buf, user.email_addr);
    md5_block((unsigned char*)buf, strlen(buf), cpid);

    if (rain.data) {
    fprintf(f,
        "<user>"
        " <id>%lu</id>"
        " <trac>%f</trac>"
        " <rac>%f</rac>"
        " <cpid>%s</cpid>"
        " <rain>%s</rain>"
        "</user>",
        user.id,
        user.total_credit,
        user.expavg_credit,
        cpid,
        rain.data
    );
    }
}

(Bear in mind that 'rain' is old terminology, still to be changed)

The above export would only include users whom have supplied 'rain' information (aka "user data" once renamed) will be included in the export (immediately eliminating 99.5% of the userbase). Likewise, several unnecessary user.xml fields have been removed (no name, postal code, team id, URL, exp_avg_time, create_time, country.

If the Gridcoin network was to download this file instead of the user.xml.gz file, we would decrease the bandwidth strain on BOINC projects significantly as this minimized xml.gz file would be far smaller than the user.xml.gz files.

If this extract was accepted, the inclusion of this new field in the user.xml (and associated user.xml.gz extract) could be dropped so as to prevent inflating these existing files, and potentially prevent having a negative impact on established statistics services which parse these user.xml.gz extracts.

I'd like to make it clear that whilst this individual post heavily references Gridcoin (and the issue itself referencing crypto), the introduction of this single 'user data' field would be for the benefit of all 3rd party projects considering integration with BOINC, not just Gridcoin. I have several ideas for such a field which have no relevance to Gridcoin.

Would it be appropriate to close this issue & raise a new issue for introducing a single field to the profile?

@ChristianBeer

This has the potential of scarring away funding agencies for example.

I do not understand. Could you expand on this fear? What funding agencies have given to BOINC or BOINC projects in the past and how would Blockchain-funding scare any potential future funding agencies away? Why would scaring large funding institutions away from BOINC in favor of decentralized funding at much greater levels coupled with the creation of a much larger grid computing network be bad?

Further, how do you see funding playing a roll in BOINC development? In BOINC Project development?

I would like to stress that blockchain based incentive structures, while they may have stemmed from communities which built virtual currencies, are not virtual currencies. They are very real commodities, securities, assets, or whatever various institutions decide to call them. But they are real and represent the value of certain products and services offered by countless institutions and entities. Bitcoin, for example, represents the value of the services provided by centralized trusted third party institutions such as Mastercard and Visa.

In other words, Bitcoin's blockchain does what Mastercard and Visa do, and the incentive structure of Bitcoin's blockchain represents the value of this service.

Incentive is also not necessary for the integration of blockchain technology into an industry. I think incentive has a roll to play in the growth of grid computing networks, but at this point in time blockchain incentive is untested and unsafe and I personally believe should be considered only after an extreme vetting process.

Regarding this specific proposal, I have great respect for CM and I work with him on Gridcoin, but I do not think it is time for something like this. There are risks involved that we simple cannot fully understand yet. I would like to see more use cases/examples of how this proposal changes BOINC. I would also like to see how we might stop people from using their resources to directly influence which project a volunteer chooses to crunch. I think BOINC is seeking to build something like a "free market of science" in which good projects are chosen by their ability to convince and educate people on their research topic, which is beneficial to society beyond just getting research completed.

The Governance v2 doc specifies that one of BOINC's primary missions/goals is the following:

"Is “sustainable”, i.e. does not depend on any one person, group, or funding source, and which allows and encourages volunteer participation. "

Surely the concerns around the NSF not providing BOINC funding being a primary reason to block community proposals contradicts the new governance doc? That if we're solely reliant on NSF we should be exploring alternative sources of funding?

There are risks involved that we simple cannot fully understand yet.

Given sufficient peer review of pull-requests and thorough documentation (see github repo), the risk to projects is minimal as long as:

New tables are able to be created after the project has been initially compiled.
Given zero reference to crypto in the field there is as much associated risk as users using the username field to store data. Likewise, such risk is already existent with GRC rewarding the project's volunteers without storing data in profiles. You don't see the curecoin team compromising the folding@home project despite their use of curecoin info in username fields..
Furthermore, we could include a hard-switch for project admins to entirely turn off this functionality (much like how other optional features are implemented).

I would like to see more use cases/examples of how this proposal changes BOINC.

Listing off use-cases/examples is out of scope of this issue/pr; the proposed change would include a new field in the profile and promote the use of a minimized xml gz extract over the massive user.xml.gz files which would massively reduce the bandwidth strain placed on projects (especially as say the GRC network plans to remove the team req).

I would also like to see how we might stop people from using their resources to directly influence which project a volunteer chooses to crunch.

Out of scope again, do note that despite being a gridcoin user you're proposing to combat gridcoin itself, since it promotes the whitelisted projects over the full list of available boinc projects (using its resources to influence volunteers to crunch whitelisted projects).

I think BOINC is seeking to build something like a "free market of science" in which good projects are chosen by their ability to convince and educate people on their research topic, which is beneficial to society beyond just getting research completed.

BOINC projects aren't chosen by their ability to convince/educate people on their research topics - many BOINC projects keep their research to themselves, not all are entirely open-source, some are commercial and make money from their research. The primary purpose of a BOINC project is to utilize volunteer's idle processing power for the means of crunching serious amount of any kind of distributed computation, not to educate people (fair enough this may be a bonus if they release their research).

It sounds like it's just an arbitrary custom field which can be used for anything tracking related. Or am I wrong? Cryptos would be one use case, gamification would be another.

Closing this thread, please move discussion regarding the new proposal here: https://github.com/BOINC/boinc/issues/2087

Don't let the closure of this issue prevent responses to some of the above posts though, they're relevant still in this thread (however potentially not in the new issue).

BOINC / boinc