search

BOINC / boinc

Open-source software for volunteer computing and grid computing.
https://boinc.berkeley.edu
GNU Lesser General Public License v3.0
1.99k stars 444 forks source link

Introduction of a single 'user data' field to the profile #2087

Closed grctest closed 7 years ago

grctest commented 7 years ago

Preface

For transparency reasons, the following is the related issue/pr which inspired this new proposal:

Given that the original issue no longer fully represents the new proposal, I chose to close the original issue and open this issue to focus attention away from virtual currencies solely towards the new proposal.

New proposal: Introduce a single 'user data' field to the user profile.

// Draft version - not production code!
// Note: 'rain' is old terminology - will be changed!

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>"
        " <total_credit>%f</total_credit>"
        " <expavg_credit>%f</expavg_credit>"
        " <cpid>%s</cpid>"
        " <rain>%s</rain>"
        "</user>",
        user.id,
        user.total_credit,
        user.expavg_credit,
        cpid,
        rain.data
    );
    }
}

The above export would:

I was even thinking, we could create a more optimized export than XML such as JSON however this may require using an alternative script than /sched/db_dump.cpp for interacting directly with the SQL tables from the CLI.

Thoughts?

I'm interested in your thoughts regarding the inclusion of a single additional field which uses its own table and dumped gz export?

jring-o commented 7 years ago

Please read my previous responses at https://github.com/BOINC/boinc/issues/1998#issuecomment-326821376

This is in response to @grctest and @denravonska from that post.

As this new proposal is a direct offshoot of "project rain", I think it is important to remember the initial goal of Project Rain was to reward volunteers of a specific project with more money than others. This makes people workers, and not volunteers. It also presents a danger to the BOINC project ecosystem.

Simple Crypto/Monetary Use Case as I understand it:

Basic Flow of Events:

  1. An individual or group (G) wishes to attract users to a specific project.
  2. G tracks the contributions of volunteers to that specific project.
  3. G rewards the volunteers of that specific project using X (money, crypto, whatever)

This encourages volunteers to work on projects which offer greater monetary rewards than others.

If G has a large purse, let's say 100 million dollars, they have the potential to "steal" the volunteers from all other projects for an extended period of time. If it is more economical to use BOINC in this way than to rent a centralized super computer, G will take this path. As I see it, that presents a 0-day attack vector, particularly without any regulatory protocols, as proposed in this thread.

This proposal will make GRC(crypto) value directly tied to computing processing: If I buy a lot of GRC I can convince people to crunch my project. GRC in this scenario could be replaced with anything of value -- any cryptocurrency or maybe even tulips if that whole thing happens again.

Instead, I would support a project funding proposal which does not encourage volunteers to change projects in search for greater profit. I do believe that volunteers should be rewarded for their work -- it costs money to run computers and in fact they are providing a service of real value: super computing. But I believe the project ecosystem should rely on G's (from the above use-case) ability to educate volunteers as to the real value of the research supported by G, not on how much money G has.

I could be misunderstanding the use case, so please correct.

I would love to see more detailed examples of how this functionality might be used other than with regards to monetary reward.

Additionally, I understand how this proposal will make it easier for GRC and other third party entities to operate with BOINC, but I think the potential dangers greatly outweigh this singular benefit. There must be a better way.

I am new here, so for anyone not from the Gridcoin community I have made an introduction post. Please check it out = )

http://boinc.berkeley.edu/dev/forum_thread.php?id=11815

grctest commented 7 years ago

Please read my previous responses at #1998 (comment) This is in response to @grctest and @denravonska from that post.

Responding to #1998 directly instead of disregarding responses & cross posting would be appreciated.

As this new proposal is a direct offshoot of "project rain", I think it is important to remember the initial goal of Project Rain was to reward volunteers of a specific project with more money than others.

In the transparent preface I made the historical relation to the project rain issue/pr clear; this proposal has no relevance to any specific virtual currency nor any external system. It is a neutral 'user data' field for any third party service/project/network to store data in. I requested that virtual currency discussions stay in the old thread as they aren't the focus of this proposal.

Frankly these goals you reference are a misrepresentation of the 'Project Rain' repo, there were no specific 'goals' behind project-rain (See repo readme), the idea was to provide anyone the tools to compete directly with Gridcoin - competition is great for innovation & volunteers earning many tokens instead of one is a desirable outcome for aiding user retention (aiding in offsetting electricity bills). That said, the contents of the 'Project Rain' repo were rejected and are not the focus of this issue's proposal.

If G has a large purse, let's say 100 million dollars, they have the potential to "steal" the volunteers from all other projects for an extended period of time. If it is more economical to use BOINC in this way than to rent a centralized super computer, G will take this path.

If you've got $100m, you're going to be using a known cloud computing provider or have your own computing capacity rather than relying on volunteer computing which likely wouldn't be suitable for their business needs regardless of the cost benefits of volunteer computing.

Even if this field wasn't added to BOINC, anyone can create their own BOINC project with this functionality. A competitor to Gridcoin would certainly be possible - competition is a good thing especially when it's beneficial for the volunteer performing the computation.

As I see it, that presents a 0-day attack vector, particularly without any regulatory protocols, as proposed in this thread.

That's absurd, this proposal doesn't introduce any software vulnerabilities, implying so is dishonest.

Users moving between projects to focus on profit has been a reality ever since CPU/GPU mining became a thing - each crypto could be viewed as this $100m imaginary fatcat you refer to.

Users interests/reality/living-situations/finances vary constantly - each influencing their retention likelihood, we should embrace projects and services which aim to integrate with and promote the BOINC network to new & idle BOINC users.

This makes people workers, and not volunteers.

If the project admins directly pay their users with virtual currencies, they are potentially workers - if you're planning on distributing a token to your own volunteers then you should consult an accountant.

If volunteers receive rewards from a third party (not the project admins/owners) then they are not magically converted from a volunteer to a worker as a result.

It also presents a danger to the BOINC project ecosystem.

I completely disagree, it poses as much a danger as any other profile field (in other words no danger), unless a dev can point out any issues with creating a new SQL table in an existing project? If anything, it benefits BOINC projects by promoting minimized extracts over the full-size user.xml.gz files.

SETIguy commented 7 years ago

I don't have a problem with a user data field if it's implemented safely. I just want to point out that if user data is a project specific user input that's expected to contain XML, project specific code is going to be used to scrub it. The BOINC code can't scrub it without removing the XML tags.

Seems a little dangerous to me, especially if share between projects or dumped with the stats. Anyone else see a "Little Bobby Tables" problem? Maybe base64 encode the field before storage, but then it's no longer human readable.

On Sun, Sep 3, 2017 at 2:02 PM, CM notifications@github.com wrote:

As this new proposal is a direct offshoot of "project rain", I think it is important to remember the initial goal of Project Rain was to reward volunteers of a specific project with more money than others.

I disclosed this in the preface, you're not disclosing new information here.

This makes people workers, and not volunteers.

If the project admins directly pay their users with virtual currencies, they are workers. If they receive rewards from a third party, they are not magically converted from a volunteer to a worker because of this. If this was the case, then GRC has already caused this.

It also presents a danger to the BOINC project ecosystem.

I completely disagree, it poses as much a danger as any other profile field (in other words no danger), unless a dev can point out any issues with creating a new SQL table in an existing project? If anything, it benefits BOINC projects by promoting minimized extracts over the full-size user.xml.gz files.

Simple Crypto/Monetary Use Case as I understand it:

Entirely off topic - this proposal has no relevance to any specific virtual currency nor any external system. It is a neutral 'user data' field for any third party service/project/network to store data in. I requested that virtual currency discussions stay in the old thread as they aren't the focus of this proposal.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/BOINC/boinc/issues/2087#issuecomment-326830996, or mute the thread https://github.com/notifications/unsubscribe-auth/AKXcst-lEzKciMmJq6y39XsxmAzp1Ft9ks5sexPVgaJpZM4PLS35 .

-- Eric Korpela korpela@ssl.berkeley.edu AST:7731^29u18e3

grctest commented 7 years ago

Some further ideas:

Alternatively, given today's workshop discussion:

Why sign the UserID instead of CPID? If we were using one project to verify a CPID & the project changed their private keys then the entire CPID may be invalidated (many projects, not one) instead of a single project UserID being invalidated.

EDIT: Added to the Gridcoin-WIKI for community peer review.

grctest commented 7 years ago

I'm closing this github issue in favour of creating the following issue: https://github.com/BOINC/boinc/issues/2118