An Introduction to Manual Reward Claims(MRC)
CBR
So.
Constant Block Reward (CBR) is in the development pipeline with a proposal released and a poll running to determine the block reward value (along with some other economic factors).
The implementation of CBR is expected to bring a drastic increase in staking difficulty to the network. This means greater security and more stability. It also means that the GRC required to stake once in 6 months is going to increase.
To briefly recap why this is important:
Gridcoin rewards participants who contribute their Idle Processing Potential (IPP) to distributed computing tasks on the BOINC platform. As a participant completes tasks, they earn Gridcoin in a Research Savings Account (RSA). This Earned Research Reward (ERR) is moved from the participant's RSA to their wallet when the participant stakes a block. In order to tie a participant's RSA with their BOINC Cross-Project ID (CPID), the participant must register a Beacon. All the calculations for the CPIDs, RSAs, and their ERRs are performed in something called the Neural Net. In order to ensure that the neural net doesn't get clogged calculating idle beacons, beacons expire after 6 months. This means that participants must renew their beacon every 6 months. This means that in order to receive their ERR from their RSA, a participant must stake a block once every 6 months.
So if you have ERR in your RSA, but don't stake within 6 months, that ERR is lost.
The fact that you must stake to receive your ERR is an issue without CBR. With CBR, it becomes a problem.
The Current System
In general, individuals are encouraged to save or buy GRC so they can reach the level of "solo miner". With the current idle-APR system and resulting low network difficulty, this is arguably reasonable: Buy a few hundred GRC, or buy some processing gear and earn that GRC, and then stake your ERR.
If you don't buy your GRC, you join the pool. The pool is an incredible tool run by BGB. I respect the pool and admire the work that BGB does for Gridcoin, however there are some drawbacks to this system. For one, many people end up joining the pool. This makes the pool a major staking entity, which is a form a centralization.
Second, it is not possible to vote with your magnitude when in the pool. The pool currently hosts about 32% of the total network's magnitude. That is a significant amount of vote-weight tied up in the pool. BGB has set up internal voting for the pool which allows us to gauge interest, but those results are based on trust, and not an open-ledger.
Third, it can be argued that encouraging people to purchase GRC in order to receive their ERR by staking supports the price of GRC and is therefore good for the network at large. However, the pool provides a means to circumvent this artificial demand mechanism.
Without CBR, these issues as they stand provide enough incentive to develop a means of distributing ERR without forcing a participant to stake a block.
With CBR, more people will join the pool to receive their ERR, making all three of these issues more pronounced.
I want to stress: The pool is great. BGB is awesome. The pool is not a problem. Being forced to stake to receive your ERR is a problem. The pool (and others) can exist in perpetuity. It provides, at the very least, a platform for simplified project management. How it functions and why it operates might need to change as the Gridcoin protocol evolves.
Manual Reward Claims (MRC)
So where does this leave us?
We need a way, other than staking, to move a participant's ERR from their RSA to their wallet.
There have been a few ideas tossed around. My favorite is Manual Reward Claims (MRC).
With MRC, a participant can manually claim their ERR in an upcoming block for a small anti-spam fee. Standard staking could still serve to release ERR from a participants RSA to their wallet, or that function of staking could be removed.
You can think of MRC as similar to how rewards are claimed with steemit -- the push of a button.
As mentioned, developing MRC would require an anti-spam fee. An anti-spam fee is the same as the fee paid for making a transaction, sending a beacon, or registering a vote. This fee, let's call it the MRC-Fee, adds an economic tool to the Gridcoin network. Ask yourself, what do we do with these fees?
A few possibilities:
- Distribute to stakers of blocks
- Distribute to the GRC Foundation
- Use to fund Gridcoin development through a treasury system
- Use to support BOINC projects, charities, relief efforts, causes, scientific research (grants?), and crowd-sourcing endeavors
- Burn to control inflation
- All of the above
Moving Forward
We are going to want to have MRC thought out before CBR is implement, so let's get this conversation rolling. Along with adding to, correcting, and refuting everything I said above, please share concerns and questions, and definitely share anything that can be added to the following two lists.
Problems
- Scaling (Currently 3,500 active beacons, 14,000 pool users, 960 blocks per day)
- Spam
- Security
- Logistics
Solutions
- High transaction protocols in development
- MRC-Fees
- Learning from existing platforms
For Science!
I think we should probably treat all fees the same way, they either all get burned, all go to stakers etc. As Gridcoin has no cap I'd suggest burning is the best method.
In terms of spam, can't we set a minimum reclaim amount?
EDIT: To make the process simple, we should probably auto-claim rewards on a schedule, say weekly provided they are above the minimum amount, but allow users to manually claim more frequently.
What do you think about @noah-blaker's idea of having a minimum burn amount, for example, then splitting the rest in some other way, either as defined by the protocol or as defined by the user?
Yeah Im in favour of the side-staking idea, I raised it a while back on Slack. I run Pinkcoin and it seems to work well the way they have it implemented. I like the concept of taking small amounts that you hardly notice and building funds to do valuable things with.
What I'd like to see is a system where the user gets to choose where their fee goes. I think we should have a base fee for the transaction data (0.001 grc/kb or whatever it is), then on top of that a base burn amount is required.
The transaction fee and burn amount together is the minimum that is deducted from claiming your RR.
On top of that, the user gets to chose where an amount of coins goes. You would get the option to send them too:
This is very comparable to previous discussions on side-staking.
Alternatively, you can substitute the burn amount for an increased transaction fee, and it just goes to the staker of the block.
EDIT: I've been thinking and I would like to revise my original thought: If gridcoin is a research based blockchain, then why should we burn coins by deducting it from the Research Reward? Also, is it really "burning" if those coins never existed in the first place?
I opt for an implicit transaction fee based on the size of the data and a minimum claimable amount.
Excellent post @jringo. I have one slight clarification I'd like to make:
The pools don't stake terribly frequently. Each of the three grcpool accounts have less than 200k GRC (correct me if I'm wrong here). Thus I would not classify the pools as a "major staking entity" at least in terms of Proof of Stake.
The centralization risk is that currently more than a third of all POR rewards go to the pools. This makes the pool a massive target. I also respect BGB and all the great work he does, but the pools having so much control of the POR payouts makes them a very juicy target for would-be attackers.
whoa. yeah that's a good point.
also:
To avoid this being an issue, you could put a higher fee that decreases the longer you wait between use? I dont have any idea what the fee is intended to be but let's say it's 7 GRC for the sake of conversation
on day 1 you claim, it costs you 7 GRC, every day that fee would decrease by 0.5 GRC until it reaches the minimum of 0.5 GRC after 2 weeks
Think this is already solved by relatively high fees for manual claiming, but you could always implement a minimum delay based on the same timer as staking in a way that when you manual claim, your staking countdown is reset and you cant manual claim if you dont have coins to stake?
Can you expand on the security issues related to Manual Reward Claiming please?
Or perhaps a minimum claims balance before being able to claim it?
Do you mean a minimum balance in the participant's RSA before they can claim it?
Or a minimum balance in the user's wallet before they can use MRC?
Min incoming balance via POR before claiming manually.
brought this idea up during the hangout today. positive response.
That could work but it has to be small enough that people with really low end machines like PIs can claim within 6 month, ideally once a month. this way you can at least get 6 rewards on one beacon
Yeah, perhaps it could be a min of 1 or a % of monthly earnings?
I don't know specifics -- it's just good practice to be thinking about security when starting discussions on development. = )
oh right, I thought you had something specific in mind.