Gridcoin Research 4.0 Proposals and Preliminary Polls

in #gridcoin2 years ago (edited)


Gridcoin Community,

It is my honor to present to you the proposals and polls which will lay the foundation for the Gridcoin Research 4.0 development roadmap! This document has been compiled from issues and proposals posted on github and discussed among the community over the past several months. Work has been put in during this time by @barton26, @caraka, The Earl of Annandale, @jringo, quezacoatl, @skcin, and @tomasbrod. This article and the results of the polls it proposes are meant to provide the groundwork for actionable discussions and will serve to inform the Gridcoin Roadmap going into 2018. You will see that there are some topics we can easily summarize in a few sentences as they are mainly bug fixes. Others are bigger, structural tasks that have been a matter of discussion for some time. Most of these proposals require mandatory updates. For these proposals, a valid poll is one which is verifiably created by one of the individuals involved with compiling this article. Furthermore, only polls which reach at least 15% of the available vote share by their closing will be valid. All valid polls will be used to inform the Gridcoin 4.0 Roadmap for 2018.

The implementation timeline works to group updates based on priority and efficiency while minimizing the number of mandatory updates. A draft can be found in the form of a github project board here:

In the process of these discussions, we ask that everyone remember that we are all here to enjoy and contribute to the Gridcoin adventure and we all seek the continued growth and development of Gridcoin, for science!

First of all, here are our goals:

  • Simplify BOINC reward logic and pay more often
  • Secure blockchain
  • Create an accurate and fair rewards distribution
  • Remove or reduce the barrier for low balance researchers to earn their rewards
  • Stable and secure superblocks
  • Secure beacons or account associations
  • Remove Team Requirement
  • Combine mandatory updates into as few updates as possible

And here is the timeline for between now and when the polls close:

This proposal includes a timeline spanning 6 weeks of discussion before any decisions are made. During this time, there will be a Gridcoin Hangout every Saturday at 7pm UTC. All hangouts will be available to stream within 24 hours of ending.

  • November 3rd - This article is posted
  • November 4th: Proposal Focused Hangout - General discussion and questions regarding this article, its creation, its intent, and its content
  • November 11th: Regularly Scheduled Hangout - The focus for this article's segment will be on Constant Block Reward proposals
  • November 16th - Constant Block Reward proposal preliminary list is posted
  • November 18th: Proposal Focused Hangout - Discussion regarding Constant Block Reward proposals, and questions regarding other proposals in this article.
  • November 19th - Final Constant Block Reward proposals list posted
  • November 20th - All polls are made.
  • November 25th: Regularly Scheduled Hangout
  • December 2nd: Proposal Focused Hangout
  • December 9th: Regularly Scheduled Hangout
  • December 16th - Polls close at 7:00pm UTC
  • December 16th: Regularly Scheduled Hangout - Results Announced. Party. Hangouts return to their regular bi monthly schedule.
  • January 1st, 2018 - 2018 Roadmap released. Happy new year!

Let's dive right in



  1. Stats and Magnitude gathering - "Superblocks"
  2. Reward Calculation - Research and Staked
  3. Research Reward Payouts
  4. Account association - "Beacons"
  5. Sharedrop and Switching code base
  6. Additional Improvements and How to Help
  7. Proposal dependencies and implementation difficulty estimate

1. Stats and Magnitude gathering - "Superblocks"

Recent Average Credit is a project specific algorithm that calculates credits earned in relation to time. Credits are the BOINC reward units distributed to users for completed and verified work units. Superblocks are the mechanisms that gather stats from BOINC projects. Magnitude determines GRC earned through research and is currently determined largely by RAC. We propose replacing the use of RAC for magnitude calculation with a Total Credit Delta system. We also propose a new way of forming Superblocks called Dynamic Witness Participation.

Total Credit Delta

The RAC algorithm serves as a smoothing function, a tool to reduce the effect of volatility in a system. RAC is notoriously difficult to estimate and the RAC to magnitude relationship is even trickier. Total Credit Delta seeks to solve this difficulty while providing other enhancements at the expense of the smoothing properties of RAC.

Total Credit Delta would use the difference in a users credit between superblocks to calculate "TCD". TCD would then translate into Magnitude. This change paired with the update outlined in the section "Reward Calculation" will simplify the earnings prediction processes and open the door for simple earnings calculators. Without a smoothing function, Total Credit Delta will bring us closer to a direct Compute to GRC relationship, though the calculation of credits will remain a subject for further exploration. The lack of a smoothing function also introduces increased reward volatility. Users will no longer be guaranteed rewards when they are not actively researching. This solves the RAC exploit where a user can charge their RAC through a short period of intense crunching and reap the rewards as their RAC slow decays. It also removes the charge time required for new users to reach their full reward potential, a common complaint.

The poll will look something like this:

[ ] RAC - No change
[ ] TCD

Further Reading:

@jefpatat has been running an experiment exploring RAC, take a look:

Dynamic Witness Participation

Gridcoin currently forms a superblock by having all nodes request data from each whitelisted project simultaneously. This process causes high network and server load and does not scale. Additionally, a failed project might invalidate an entire superblock, delaying updates for all projects until the next accepted superblock.

Dynamic Witness Participation intends to increase stability and speed of superblock creation on the Gridcoin network by solving these issues. Dynamic Witness Participation will serve to replace the stats gathering aspect of what is now called the "Neural Network" with a new C++ iteration integrated directly into the client, making the network cross-platform.


Dynamic Witness Participation will inherit the dynamic selection of delegate nodes. Only the delegate nodes download the necessary data from the project servers and work on creation of the superblock. The algorithm will run independently on different projects to reduce network load and to prevent one project from negatively affecting the statistics collection of other projects.

Any node willing to serve as delegates in the creation of a superblock will indicate such in a staked block. When too many nodes are willing to serve as delegate, the network chooses a subset through a dynamic selection process. This limits the number of active connections and decreases stress on BOINC project servers. Once selected, all delegate nodes download the project stats data, process it into a sharable form and place a vote for their version. Delegate nodes then form a consensus on the data set to be used in the superblock. Finally, a delegate node with the agreed upon data set is randomly chosen to create the superblock and end the process.

Honest delegate nodes will be rewarded with extra GRC for creating the superblock and voting. The bonus DWP rewards are meant only as a minor additional incentive and gamification tool, not as a primary source of GRC mint. Details on reward are in the next section, "Reward Calculation".

Details of this processes can be found here:

The poll will look something like this:

As we are continuing to explore this and other potential options, this poll will serve as an opinion poll.

[ ] Continue exploring DWP
[ ] I do not think DWP holds potential

Further Reading:

2. Reward Calculation - Research and Staked

There are two major issues with current reward calculations. First, the calculation of magnitude is unecessarily complex and the total research reward calculations have been failing. To solve these issues, we propose setting a new standard for GRC production by directly relating magnitude to GRC produced by research per day. Second, Gridcoin's interest payment system does nothing to encourage a user to contribute large staking balances to the blockchain. To solve this issue, we propose replacing interest with a Constant Block Reward protocol which rewards a set number of GRC to the staker of a block. Constant Block Reward has the added benefit of synergizing with Dynamic Witness Participation (detailed above) and potential future developments, such as Sidestaking (detailed in the section "Additional Improvements").

Constant Block Reward with Magnitude and Supply Readjustment

Gridcoin rewards GRC for researching with BOINC and for staking blocks for its blockchain.

Gridcoin's current logic of BOINC research payments is quite complex. A combination of a 14-day "kitty" plus the magnitude unit are in charge of GRC production. Right now we have 115,000 overall magnitude and a dynamic magnitude unit of about 0.2-0.25. This means that 1 magnitude produces 0.2-0.25 GRC / day. This leads to a reduced GRC production via research payments. On average, 27,103.08 GRC per day has been produced via research rewards in blocks 1,020,000 to 1,059,000. This is little more than half of the intended 48,000 GRC per day. To simplify and correct this structure, we propose setting the magnitude unit to 1. This basically makes magnitude equivalent to GRC produced through research per day: 48,000 magnitude = 48,000 GRC produced by research per day. To implement this change, the community will need to choose an overall magnitude.

Gridcoin provides a transaction fee reward for staking a block. As a result, many users with large balances do not contribute to securing the blockchain. They do this because Gridcoin promises 1.5% interest on all GRC in circulation so long as the GRC stakes a block. This means that a GRC coin can be kept offline indefinitely, and as soon as it is brought online it receives all interest it is owed. If you receive benefits regardless of how much you help secure the blockchain, and the reward for staking a block is negligible, why would you help secure the blockchain? Gridcoin suffers vulnerability to forks and other blockchain disruptions due to this economic model which separates reward from service.

We propose removing interest earned and replacing it with Constant Block Reward. Essentially, each block staked will reward the staking node with a set number of GRC. This will stop rewarding idle coins, forcing investors to stake in order to earn idle profit, which in truth will no longer be idle profit. The increase in blockchain security is good for all of Gridcoin as it provides stability and brings more trust to the Gridcoin network. To implement this change, the community will need to choose a GRC value to serve as block reward. It is also possible, though not necessary, to reward superblock creators with extra GRC along with delegate nodes outlined in the Dynamic Witness Participation section above.

While these two updates are not dependent on one another, we believe they are both necessary and as they constitute the foundation of the Gridcoin Network's economy, are implemented best when tied together.

To implement these changes we propose the community vote on all reasonable combinations put forward in the 3 week period following the posting of this article. Proposals can be posted on Steemit, reddit, slack, irc, or cct. We will post a preliminary list on steemit on November 16th, two days before the hangout on November 18th. Any proposals wishing to be added after the preliminary list is posted must add their proposals in the comments of that steemit thread. Reasonable proposals from that thread will be added to the poll up to 24 hours before the poll is made on November 20th. To be considered, a proposal must at least contain information regarding the following aspects along with reasoning. These proposals will help define the GRC economy for at least the next year, so be as detailed as possible.

  • GRC minted by Research per Day (equals to total magnitude)
  • GRC minted by Research per Year (total magnitude * 365)
  • GRC minted by CBR per Day (GRC reward per block * 960 blocks)
  • GRC minted by CBR per Year (GRC reward per block * 960 blocks * 365)
  • Differences between the proposal's economics and the current interest economics - as detailed as possible.
  • Overall economic effects and predictions of the proposed values (Magnitude and CBR)
  • Bonuses for DWP Superblock creators and delegates (in case we implement DWP)

The recently added getblockstats RPC command might prove useful in your calculations:

If your proposal is similar to another one, we encourage you to team up and compromise in order to help consolidate the number of poll choices.

The poll will look something like this:

[ ] Proposal 1: 50,000 overall magnitude with 15 GRC per block + X superblock reward + Y delegate reward
[ ] Proposal 2: 50,000 overall magnitude with 15 GRC per block no extra reward
[ ] Proposal 3: 50,000 overall magnitude with 10 GRC per block + X superblock reward + Y delegate reward
[ ] Proposal 4: 26,000 overall magnitude with 10 GRC per block no extra reward
[ ] Proposal 5: 26,000 overall magnitude with 0.5 per block no extra reward
[ ] Proposal 6: ...
[ ] ...
[ ] maintain current protocol: 115,000 mag, dynamic mag unit, kitty and current DPoR output persist
[ ] Search for alternatives

House Keeping - "Trapezioid" Bug Fix

Currently, a slightly different formula is used when the time between rewards crosses 20 days. The formula basically requires all blocks to be scanned on startup in order to work properly. This makes the process for a user receiving their first reward, or when the previous reward was more than 6 months old, incredibly complicated, often resulting in significant reward losses. We want to replace this calculation to a more accurate one which will reward users fairly for all the work they do. This proposal would require a mandatory update.

This update will not require a poll.

Further Reading:
Poll 1
Poll 2

3. Research Reward Payouts

Research reward payouts are currently bound to PoS payments which are bound to block creation. To create a new block and collect both rewards, a miner must find a valid PoS kernel. Depending on the miner's balance, this can take a very long time. This is a common and very reasonable complaint of users without high balances. Joining an external pool helps a lot, but pool users can't vote with mangintude and their BOINC work is logged under the pool's name, not their own.

There are three proposals to improve the current system of distributing research reward.

Manual Rewards Claim

Manual Rewards Claim intends to provide an alternative to CoinStake and pool staking with the intent to increase accessibility to owed research rewards for non-staking balance users. Additionally, Manual Rewards Claim adds an economic tool to the Gridcoin ecosystem in the form of Manual Claim Fees.

Manual Rewards Claim works much like the rewards claiming of steemit. At any time, a user would have the option to manually claim their earned research rewards in an upcoming block. This claim system would function as an alternative to standard staking and pools, which would remain unaffected. To prevent spam, a fee similar to a transaction fee would be required to manually claim your rewards. This is the Manual Claim Fee.

It is possible, though not immediately necessary, to distribute Manual Claim Fees to an array of entities such as: stakers, The GRC Foundation, BOINC projects - to subsidize server costs and security, charities, relief efforts, causes and crowd-sourcing, or fees could be burned to help combat inflation. There would need to be an extended conversation after the implementation of Manual Rewards Claim to determine a future path. For simplicity of implementation it might make most sense to treat Manual Claim Fees as transactions fees: They are to be added to blocks as rewards for staking.

Manual Rewards Claim acts as a bridge between pool use and solo use. Pools are a critical part of the Gridcoin ecosystem, and the cryptocurrency world in general. Their purpose with Gridcoin is to help users with entry level balances stake and receive their research rewards more often. Currently, when a user earns enough GRC to stake on their own they choose to stay with or to leave the pool. With Manual Rewards Claim, when a user has enough magnitude to earn more than the cost of the Manual Claim Fee, they can choose between continued pool use, or paying the fee.

If we agree to implement Manual Rewards Claim, we might need to have a second poll to determine how the Manual Claim Fee is calculated.

Beacon Mint

Stake V8 removed researchers from the process of securing the blockchain. This was done for security reasons, however it presented an interesting question: Do we want the blockchain to be secured solely by PoS, or do we want Research involved by reintroducing a Proof of Research protocol?

Beacon Mint is a moderately secure block creation scheme that weights stakers not only by their mature GRC balance, but also by the amount of rewards that they are owed. This alternative gives Researchers part of the responsibility of securing the blockchain.

In short, Beacon Mint splits block creation into two fields: Standard PoS blocks and Beacon Mint blocks. To prevent age bunkering attacks, there will be a required number of PoS blocks created between Beacon Mint blocks. Beacon Mint blocks are created by keeping track of the research rewards owed to a specific beacon. As this number rises, so does the Researcher's likelyhood to stake through the Beacon Mint mechanism. This number continues to rise until the beacon creates a block, at which point the process resets. It might be possible to impliment Beacon Mint with Manual Rewards Claim, however more research is required to determine the economic implications.

The details and security of Beacon Mint can be found here:

Super Block Payout

Another alternative is to pay all rewards in superblocks. The upsides are frequent payouts for everyone, including new users. On the downside, there is no incentive to hold mined coins. The large volume of transactions would also mean that the block size limit would likely have to be lifted for the size of these superblocks.

The poll will look something like this:

[ ] No Change
[ ] Manual Rewards Claim
[ ] Beacon Mint
[ ] Super Block Payout
[ ] Search for alternatives

4. Account Association - "Beacons"

Currently what binds your wallet to a BOINC CPID is called a beacon. The beacon system is not entirely secure and not entirely stable... it has been a fix a long time coming. Users are complaining about split CPIDs, unexpected CPID changes, and bad beacon keys. The new system may stop using CPIDs altogether and use the Account IDs instead, as CPIDs are both not very secure and can change unexpectedly. Additionally the current system requires the user to supply an email address for their wallet, which is something we're hoping to do away with.

There are two proposals. Both of them deprecate CPIDs and require either automatic or manual registration of each project account separately into the Gridcoin reward system.


BrodSAA alternative requires the user to copy a string from their wallet into their BOINC project account (name or url,...), then register the project in their wallet. In the background the Gridcoin network (the DWP nodes) will process and verify the registration against the project server. The extra text can be removed after the registration is complete. This all works without modification of the BOINC server software.


CM-SAA alternative involves a special page on the BOINC project website where the user must copy a string from their wallet and then copy the response back to the wallet to complete the registration. Creating that custom page does involve modification to core BOINC software. BOINC maintainers are against any crypto-currency related modifications plus there are projects running outdated software versions, it will take years for them all to upgrade. On the other hand these registrations are much faster to verify.

The poll will look something like this:

This section is intended to spread awareness and initiate a discussion regarding a long standing issue. We intend to explore and develop these and other possible improvements to the BOINC-Gridcoin interface and hope to present an actionable poll some time within the coming 6 month Gridcoin Foundation payment block. We encourage anyone interested in learning more to read the wiki linked in Further Reading where additional options are being presented. Beyond that, let's get thinking.

There is no poll for this section.

Further Reading:

5. Sharedrop and Switching Codebase

This protocol extends on the idea by @cm-steem to transfer Gridcoin to a new codebase and blockchain. It was recently shown by Martin Grothe that some private information can be recovered from the blockchain and since we can't just change data in a blockchain (a Hash List) we need a way to transfer the account balances to a new chain. This protocol aims to do this process securely; that is without a single entity governing the process. Instead, the users of Gridcoin will have a share on validating the whole transition.


Two chains will run in parallel for some time. The new chain will start with a Genesis block as coins usually do. But the mint mechanism on the new chain will be an absolutely new thing. Not PoW, not PoS, but blocks on the new chain will be secured by blocks from the old. Sharedrop is a process of translating unspent transactions from the old chain into the new blocks. Since the old chain continues to run, both historic and new transactions must be translated and gradually included in blocks. The challenge is that transactions on new chain will have different hashes than on old. Eventually Proof of Stake and research rewards will be enabled on this new chain to complete the transition and split for good.

Up to the point of final splitting, the operation will be mostly silent for average user. Users will not be required to update unless they are large investors and want to help.


Switching to a new and clean codebase involves porting a lot of code. The work done implementing the proposals in this article on the old codebase would have to be duplicated for the new. Spending time and money on the complex changes twice does not make sense. Some of the proposals, however, are important for security of the blockchain or easy to do. The decision, which changes to implement now and which after the switch, will be made by developers.

The poll will look something like this:

[ ] Yes
[ ] No
[ ] Search for alternatives

Further Reading:

Martin Grothe Post:

6. Additional Improvements and How to Help

These are improvements and issues we are currently exploring and hope to see developed or addressed within a year. If you would like to contribute to these or any of the proposed developments in this article, or if you have other potential improvements, we encourage you to reach out through any active community channel which can be found at Approved developer work is paid hourly from the Gridcoin Foundation. Details regarding payment can be found at:

  • Cold Staking: A mechanism that allows whales to leave significant balance(s) in cold storage, while a wallet kept online stakes on behalf of the cold keys. This would encourage whales to keep a wallet always online without fear of getting their balance hacked. Whales could potentially vote from such a wallet, representing their whole balance without having to crack open cold storage.

  • Sidestaking: A mechanism that distributes funds to a wide array of possible entities and projects. This can be implemented in the staking rewards structures, transaction fees structures, and/or the Manual Claim Fees structures. Sidestaking might present a fair and secure way to fund BOINC projects, Gridcoin marketing campaigns, bounty based developments, faucets, general research, charities and relief efforts, personal projects, and other endeavors. Fund distribution could be manual, automatic, static, dynamic, or a combination, and could be tied into the network and its economic requirements. For example, a portion of fees could automatically and dynamically be allocated to a burn sidestake address or to block creation rewards based on the measured needs of the network.

  • The Greylist: A mechanism which helps on-board new BOINC projects while providing automated maintenance to the active whitelist. The Greylist could serve as a temporary stop for projects wishing to be whitelisted. This would allow time for project vetting, while giving researchers time to learn about the project and adjust their crunching as desired. Additionally, the Greylist could automatically assume contact responsibilities with projects which go down, fail to distribute work units, or whatever we choose. Projects would then automatically be rewhitelisted when they fix the issue. After a certain time on the greylist, the project would be removed from the greylist and would have to go through the whitelist process again from the beginning. This would encourage project maintenance and communication while reducing work required for superblock formation.

  • Reduce memory usage, load time and fork-stability:

  • Reduce blockchain space usage by implementing better serialization format and merging the Coinbase and Coinstake special transactions

  • Improved user experience, and wallet graphical interface

7. Proposal Dependencies and Implementation Difficulty Estimate

  • Constant Block Reward -> done
  • Mag Unit change -> easy
  • Beacon Mint -> easy
  • Manual Rewards Claim -> moderate
  • CM-SAA -> moderate
  • RAC to TCD -> moderate, better with DWP
  • BrodSAA -> after DWP easy, without it hard
  • Trapezoid fix -> easier said than done due to current code structure
  • DWP -> hard

Further Reading

Thank you for taking the time to involve yourself with the growth and development of Gridcoin. All of us are eager to see Gridcoin excel and look forward to the coming discussions.

The Steem rewards from this article will be translated into GRC on Bitshares and used to pay for editing the hangouts.


The Earl of Annandale

A Personal Note from Myself

Every time someone comes into the community and asks for a lead dev, 2 things happen:

  1. People explain that there are no lead devs. We are open source submission.
  2. People list who they would consider a lead dev.

@ravon is one person who is on everyone's list as a lead dev. It should be noted that he has not yet signed on to this article and these proposals. This is not because of subversion or cliques or any of that FUD. He is simply a busy man. He is aware of this article and all of us look forward to hearing his thoughts. At the same time, if we want to get a 2018 Roadmap out by 2018, these discussions need to start in an "official" capacity immediately. There is plenty of time and opportunity for discussion before polls are made.

Also, seeing the work put into this by so many people is inspiring. From the bottom of my heart, thank you to everyone for everything you do, and thank you for the coming discussions.

Now, let's get this done.


Find the edited recordings of the first discussion here:


Please note that this article is a result of collaborative work. Unfortunately Steemit does not allow posting with multiple authors. We all, @barton26, @caraka, TheEarl, @jringo, quezacoatl, @skcin, and me worked on it. Thank all the authors.

Excellent work. I'm excited for 2018!!

Today's discussion was 3 hours of general overview regarding the article and proposals along with some amazing questions, concerns, suggestions. We will do our best to get it edited and uploaded by tomorrow at 10pm UTC, so keep your ears to the ground.

There will be a "progress report" thread posted either Thursday or Friday every week going forward. This report is intended to summarize the week's discussions, general FAQ, and common concerns regarding the proposals. Next week is the regularly scheduled hangout hosted by @peppernrino, so if you have other Gridcoin related topics you would like to discuss, be sure to get them on the thread!

November 20th - All polls are made.
December 16th - Polls close at 7:00pm UTC

This is an insufficient period of time for substantial development polls. I had people freaking out over a single month in the past (with regards to the fixed/posv3 block reward poll), the suggested minimum is 3 months so that we can maximize involvement, otherwise it can be seen as subversion.

One month seems fine; perhaps this can be a discussion point at the hangout.

manual reward, superblock payouts

I'm not a fan of decoupling GRC From POR, however with the current economic policy we're between 150-200, so if proven 100% secure I'd be far more in favour of manual rewards over superblock payments.

A concern though is that what if I hit the 'manual payout' button non stop, effectively dosing the GRC network with POR reward transactions which need to be verified, there'd need to be a minimum time between manual payouts (both local and network peer check) if it's a computationally expensive check that's being performed.

beacon mint

Sounds close to the old system, but i'm apprehensive given the previous system's vulnerability to which tomas brod's weaponized exploit was capable of generating blocks at will - this could have destroyed gridcoin had any script kiddle felt like it.

Superblock payments

Thousands of users payments needing verified in a single block would potentially require greater compute time than a traditional block which only verifies a single user's POR rewards right?

Likewise, I'm not confident in such an approach given the recent superblock insecurity/instability, wasn't brod effectively able to force SBs to the rest of the network?

When no-one is running NN on testnet except you, sure you can force whatever SB you want. Sam with DWP. Participating in NN is important for this reason.

Remove or reduce the barrier for low balance researchers to earn their rewards

There's the open source pool for this, no need to change Gridcoin for those unwilling to invest.

Regarding the sharedropping grc onto a fresh chain:

It can be argued that the data is out there, that the damage has been done, but you don't see equifax throwing in the towel and leaving their data effectively open to the public, they closed their vulnerability and so did we (yet our historical data is still vulnerable).
What happens if we disregard this problem and a year down the road our 10k+ NN registered (not active registration, historical) start getting email phishing/trojan attempts through freshly scraped email data?

It is a large amount of work, however we're already talking about rearchitecting the core functionality behind Gridcoin already, by snapshot/sharedropping onto a newer codebase we can take many shortcuts to desired functionality, like witnesses/delegates/committee in graphene for one.

Very relevant:


Todo for me: TCD mag, take the immediate user TCD over a averaged network TCD.


Thanks jringo! You've really raised the bar with communication to the community.
In regards to the greylist and the automation of the removal of greylisted projects from the whitelist. Could this lead to the decentralisation of the whitelisting and de-whitelisting process through polls and such?
edit: Thanks jringo and all the coauthors . Wasn't sure how much was written by who

It sure could! It could either be implemented centralized first, then automated later, or if we have someone who wants to do the work, we could make it an entirely automated process from the start.

Be sure to spread the love around, I worked on the article sure, but in this context I'm just the messenger =) Don't thank the messenger!

Nice to see you guys looking forward. Never dwell too much on the past.

About the payments out: well if we have a tool such as this one (link: - my account), it knows when was my last payout & which was my total amount of GRC on which system calculates the interests. Also system knows how much I've donated recently, so it knows about my owned research.
So, why not us that in calculations? If you pay out 200GRC to someone, it's not the same for someone with 200GRC, someone with 2.000GRC & someone with 20.000GRCs (or more). To someone with 200GRC it's 100% of owned research, to someone with 2.000GRC it's 10% of owned research & to someone with 20.000GRC it's 1% of owned research. So why not use percentage in a way to pay out the larger the amount owned?
Guys who have 20.000GRC will might be mad at 1st, but if they wait a little (a week or two), they'll be up to 10% of their wallet owned in research so they be paid out as the others.
This would make Pool absolute, as someone from the beginning will quickly get their coins & get to stay interested. While older members (myself included) will know to wait for a week to pick up the "cream".
That way also people will not ge4t out of 180 days of those coins that have not been claimed.
What do you think?

Please consider someone signing up with many accounts.

I think beacon mint incorporates the idea behind this suggestion, but instead of relying on the balance in a wallet, which as brod mentions can be manipulated, Beacon Mint considers the amount owed with relation to time. This means that as a user with high mag and low balance reaches a higher reward owed to balance ratio they will be more likely to stake, but this ratio will have no effect on the users likelihood to stake. It's easier to manipulate reward owed over balance than it is reward owed over time.

An issue with Beacon Mint I think we will need to explore is whether we can make it so people with low mag and low balance -- most new users -- can still stake in a reasonable amount of time.

As someone who likes to run a fullnode on a raspberry Pi, memory usage efficiencies are very important.
I believe the latest Bitcoin Core has improved memory handling though I didnt try it myself

Thank you guys for all the invested time, development and effort!

Great work to put all this info together.


Great work jringo.

I will be attending the GRC Classroom and I'll stay for the discussion on this post.

I'd like to see a great turn out from the community on the GRC Classroom and the following discussion.

We always need new talent to join us and 'air' their opinions and ask questions.

Thanks! See you there = )

And be sure to spread the love around. This has been and will continue to be an incredible team effort.

Recordings of the first discussion are edited and up on soundcloud.

Lets assume gridcoin network will consist of 1 million nodes / researchers (now I believe it's close to only 3000 - counting each pool as 1 researcher?). Whether bitcoin based or graphene based, will network be able to cope with such a load? Or pools are inevitable?

I've never been prouder of the GRC community, awesome job guys.

  1. I fully support continuing to explore I've never been prouder of the GRC community, awesome job guys.

  2. I fully support continuing to explore DWP

  3. I like where we are headed with proposal two - I have been an annoying voice with @erkan on securing the network.

  4. The manual rewards claim is interesting and hasn't been something we were talking about in the summer during IRC. I like the superblock pay, but I would like to learn more about what the size limit situation is - what are pros/cons. I still don't really understand the beacon mint deal so I'm going to have to read more into the github articles.

  5. N/A

  6. What private information? Is it just e-mails? If so, that's not a huge deal and not something I would be in favor of pursuing; our e-mails are already available through BOINC - we all know that. Explain more about why moving to a new block-chain is necessary. The fact-base is missing in this proposal if it is about security and private information. Cleaning up the codebase is one thing, moving to a new blockchain is something different. We've seen how we have struggled as a community over the summer to solve the superblock issue, we don't want to introduce more instability with something that isn't adding anything.

  7. Reducing memory and blockchain space are things I support. Far more important than a new UI/GUI.

Where is @erkan and @neuralminer on all this? And what are Rob's thoughts?

We need to update the codebase because it is from 2014. While doing that, we will remove the personal information from the blockchain which yes, is just e-mails.

Again, to me the blockchain itself and the code base are different things. And, why must we update the code base - I understand there are positive aspects to doing so - but it's probably not best to justify it by saying it's from 2014...are all things from 2014 logically bad? No, of course not. So let's build a compelling base. I admit, I need to do some more reading on the situation myself....

Great News! Thank you for everyone who are investing time and effort in order to making the Gridcoin better :-)

It is a fine thing to be honest, but it is also very important to be right.

- Winston Churchill