Mandatory team requirement - if removed, how to modify the NN?

[grctest]

An user within the Telegram group requested this GitHub issue to be created.

A poll has been created regarding the mandatory team requirement: https://goo.gl/dhoAaa

Question: Technical Poll : What Should We Do Regarding The Mandatory Team Requirement?

Possible Answers:

• Checklist:I Have Read The Team Requirement Cryptocointalk Thread
• We Should Work Towards The Removal Of The Mandatory Team Gridcoin Requirement
• We Should Maintain The Mandatory Team Gridcoin Requirement
• Abstain

Team requirement cryptocointalk thread: https://cryptocointalk.com/topic/44260-discussion-mandatory-team-gridcoin-membership-requirement/page-6

---

We currently face several emerging BOINC crypto competitors:

• iEx.ec - blockchain based fully distributed computing; Techcrunch covered them and BOINC but failed to mention Gridcoin.
• SONM - Created by some of the DD@H developers, they may have additional BOINC related tokens in the works too. SONM is a direct competitor & their whitepaper makes references to Gridcoin not being a true competitor due to the lack of GRC:Computation market (that's another topic potentially covered by the burning mag multiplier concept). Relevant reddit thread.

Competitors yet to materialize

• Coinami - A Cryptocurrency with DNA Sequence Alignment as Proof-of-work
• Project Rain - many smaller tokens will likely result from this.
• Curecoin devs rumored to expand to folding BOINC projects.

Non BOINC-based competitors

• Golem - Just broke $22mil+ marketcap despite a current lack of diverse computing capabilities.

---

The important question is:

How do we scale back the quantity of users producing the NN whilst increasing the scope of the NN data gathering phase?
The reason for scaling back the quantity of users responsible for producing the NN is that by increasing the scope of users included in the NN we increase the amount of data we will download from the project servers & a larger user base downloading these larger files could theoretically cause strain on the BOINC projects (accidental DDOS).

We could easily do so with a centralized MapReduce or Apache Spark NN BOINC project, however this is a step backwards in terms of decentralization.

What about some form of witness/delegate mechanism where by trusted individuals within the community are voted to be responsible for the production of the larger NN? This has been discussed lightly on the 6th page of the team requirement thread.

---

Since @gridcoin has in the past expressed an disinterest in developing such a larger scale NN in the past, what do people think of placing a bounty against the development of the larger scale NN (if this is both still Rob's stance & the community votes to remove the req)?

Cheers,
CM.

[Scalextrix]

What if we select users to download and process the NN randomly. We create a pool of users that qualify, qualification being users who run a windows wallet and are continuously staking for 1 month. I see algos like PoST are based on continous staking so assume that is possible.

[startailcoon]

I can only say that I agree, now, that we are in need of scaling up the network and make the requirements of being part of the team obsolete. How this will be done is, as pointed out, a major topic now.

I think some type of delegated witness nodes, like Steem, is a way to go. This will be quite some work tough.

[grctest]

I forgot to post this: https://steemit.com/gridcoin/@cm-steem/gridcoin-s-mandatory-team-requirement-should-it-stay-or-should-it-go

It was my final stance on the mandatory team 'Gridcoin' requirement about 7 months ago. Some of the statistics aren't accurate (like currently active BOINC users, down almost 1/2 since 👎) however most of the points still hold.

[dopeshitnetworks-irc-dopeshit-net]

If we were to Gridxit , the " Project Grey List " idea I believe would either not work or be very much more complicated to implement... That is and yes I was and am 1 of biggest " LA VIVA LA GRIDXIT " fans but while I have been drawing out the idea at least per my view as how to have it and the automation I was figuring that the whole team flag would make it a more functional system and having it all "Gridcoin" vs a mix was almost key to the system . There is much more on that latter , another thread. :) But , hay GO TEAM GRIDCOIN!

[Scalextrix]

Perhaps Im off base here, but for the NN data being pulled from the project sites without spamming. We can have a smaller amount of nodes pull the data, and then P2P share it to all other nodes for processing, but a pull node cant process the NN data and visa versa. Who pulls the data and who processes is random, and consensus weeds out mis-behaviour.
Easy for me to type, much harder for some poor soul to build I expect.

[grctest]

---

@grcjamezz wrote:

If we were to Gridxit , the " Project Grey List "idea I believe would either not work or be very much more complicated to implement... That is and yes I was and am 1 of biggest " LA VIVA LA GRIDXIT " fans but while I have been drawing out the idea at least per my view as how to have it and the automation I was figuring that the whole team flag would make it a more functional system and having its all "Gridcoin" vs a mix was almost key to the system . There is much more on that latter , another thread. :) But , hay GO TEAM GRIDCOIN!

---

I'm interested none the less to in the concept of the grey list, do you have a written summary? Or did we discuss it fully on the 4th?

I believe we could implement the grey list solely on the server_status statistics, if we were to include them in the NN superblocks then we could track server health/wu-availability to grey list projects (instead of voting them out of the whitelist).

[tomasbrod]

Put an integer d in superblock. All nodes whose d bits of hash of public key matches d bits of hash of the superblock download the stats from projects. Then node shares this data, signed with it's own key, with the network. Eventually NN nodes reach a consensus on what data is correct and someone puts it into next superblock along with information how many nodes provided correct and incorrect data and new d value. Value of d is modified so just enough nodes download the stats data.

Nodes choose their key-pairs by random then hash of public key is (practically) uniform value. Matching first d bits (or last, doesn't matter) selects a random subset from all the nodes. We can apply additional restrictions (minimal weight/magnitude). The average size of this selected subset is n*2^-d (where n is count of online nodes passing restrictions).

If the superblock hash is somehow biased (like in PoW coins begins with zeros), we can use hash as prng like so: Put m0 in superblock and assign m1=hash(m0). Then use m1 as "hash of the superblock" in first paragraph. Include m1 in next superblock.

Keypair from the beacon could be reused as keypair in first paragraph with added bonus that only researchers would be allowed to provide NN data.

Edited to add explanation. Tell me what you think :)

[tomasbrod]

Requiring tag in username is even more restrictive than requiting team membership. I see no good point in that. Lifting the team req gives freedom and creates new problems (this one). But lifting team req and imposing username tag req creates only problems.

[startailcoon]

Requiring tag in username is even more restrictive than requiting team membership. I see no good point in that

I agree with that. No requirements should be our goal here.

[grctest]

If we were to go down the route of external NN scripts (similar to how BTS/Steemit witnesses run external price feed scripts), we could utilize MapReduce or Spark jobs.

If anyone's interested, I've created a Hadoop MapReduce program for calculating individual project magnitudes:

https://mega.nz/#!FdIhiA5I!Gcvpj3d09RQdl8xyGlalZyJFh0xukz_RRFedjiIt1yQ
https://www.virustotal.com/en/file/9674b4f51a787fc8edc3b3eb237e100f245bbf7999ecde4468914ab78f575b7b/analysis/1487858614/

Edit: Only takes 4 mins to fully parse the 500MB SETI@Home XML file, not bad for a first attempt with a single core.

[grctest]

https://github.com/grctest/GRC-Magnitude-MapReduce-Hadoop

It'd be neat if we could establish a Cassandra DB, and have the BOINC projects upload the XML files directly instead of data gathering being performed by ourselves.