search

gridcoin-community / Gridcoin-Research

Gridcoin-Research
MIT License
585 stars 173 forks source link

Proposal for Incompatible improvements #341

Closed tomasbrod closed 6 years ago

tomasbrod commented 7 years ago

Hello. I started writing a wiki page about the changes that I propose to make gridcoin better. I chosen wiki format so that other developers can edit it. This issue is meant for comments, please add your ideas directly in the wiki. I would appreciate you to post comment here before doing radical changes in the document.

TheCharlatan commented 7 years ago

Do you have an example of a project, where RAC does not decay according to the standard formula? I think one of the main reasons RAC was used in the magnitude calculation is that some projects have work units of different sizes. Lets say you are a small cruncher and complete a couple of smaller, or sporadic workunits, and accrue some credits. You then get some larger work units, which take much longer to complete. This time of not accruing any credits would be overbridged by the RAC, and you would still be rewarded for your crunching. But only looking at total credits, and assuming that this effect is evened out over all users, you may fall behind in relative credit score for that time period. However, I do not regard this effect as that significant. On my machine I am able to process most work units within a day, so I am all for using total credits as means of calculating the magnitude. Also your proposal for a reward algorithm, would bridge any type of down time, be it on the boinc server, or client.

I am ignorant of what the additional benefit of hashing the Blockhash and the Merkle Root for the vote is, isn't one supposed to be dependent on the other?

iFoggz commented 7 years ago

coinbase -> I agree stake transactions could be better and consolidated to a main transaction.

BoincHash -> always room for improvements

Reward calculation -> I agree the over 20 days part is not a great idea at all. but the average for under 20 days is not so much a problem. that should be extended to 6 months. Or the average mag can just be calculated from superblock from last stake time to current within 6 months. But again if the NN has stats gathering issues this could also affect that but not so much if its over a long period of time.

I agree that mag calculation is an issue when a project goes down. But as for Rac decay I thought thats why the MAG formula divides by whitelisted project count to keep a equal amount across all projects. On top of that everyones RAC would decay at the same rate on that project. also note the project admins can modify the formulas at there choosing.

NN -> The proposal seems more towards a centralized NN and I'm against centralization. Everyone should be able to take part in the NN. The issues with who stakes the superblock the most has been the higher the balance which gives you the higher chance to stake the superblock when you have the popular vote. When this is ported to linux it will have less of these issues and linux wallets can also do there part in NN. Also why can't the most popular vote over a period of time be the one to stake the superblock? that would require the NN to have a consensus and to allow it to happen and eliminate staking weight being involved in the stake of the block.

Nice wiki by the way. look forward to reading more when more is up. Hopefully more people chime in

tomasbrod commented 7 years ago

Thanks for the input.

Effects of WU bunkering should be researched. Eg: one bunkers, then acquires a lot of credits in short period of time, high magnitude, stakes big reward and then never returns. Maybe we can fix this with average over few days back.

Good point with the merkle hash. No reason other than hash a bit more data.

NN -> I am agains centralization too. Everyone has a chance to register for next data gathering with balance weight, or even multiple times if he stakes. Then subset of the registered is chosen by random and every time different. And from nodes with popular vote, one is chosen to stake the superblock and it does not matter who, since it must match popular vote. In the old system everyone must download the data and then one (or two!) is chosen to stake by stakeweight. In the new, subset is chosen to download the and then stake.

tomasbrod commented 7 years ago

Some of the proposed changes are implemented in #364 and are being tested.

tomasbrod commented 7 years ago

When #364 is put into production network (there is still if), staking with low balance becomes even harder and some secure mechanism to boost staking of BOINC miners will be needed. Edit: staking with low balance and some magnitude as boincer becomes as hard as staking as investor (without magnitude).

grctest commented 7 years ago

some secure mechanism to boost staking of BOINC miners will be needed.

There were huppdiwupp's 2 proposals to combat this imbalance: https://github.com/gridcoin/Gridcoin-Research/issues/106#issuecomment-273633886

grctest commented 7 years ago

@gregagnew

Regarding staking rewards for individual projects, that's a step back compared to the current mechanism where by every project is rewarded in the one go - aggregated rewards are better considering many users take once every few weeks.

grctest commented 7 years ago

@gregagnew I mean that many users have very few coins, thus if they only stake once a month and they only get one of say 10 projects rewarded, they'll not earn all 10 project rewards within the 6 month cut-off period.

Rewarding all projects in the one staked block is a better idea, it's the current system. We used to reward individual projects but it wasn't efficient.

I do like the idea of using the last staked total credit, but you would need to take into account the total credit for all users in the nn for that project since the last stake to work out their magnitude (and thus their reward).

tomasbrod commented 7 years ago

I support @grctest, that staking reward for all projects at one is best.

This was an attempt about decentralizing the staking process.

What is your idea of decentralizing, @gregagnew? I am becoming confused. Anyways, I appreciate your input.

iFoggz commented 7 years ago

staking for all projects is best. :)

tomasbrod commented 7 years ago

@grctest

There were huppdiwupp's 2 proposals to combat this imbalance: #106 (comment)

There were changes since @skcin made the two proposals. For example owed amount is not taken into account when calculating nether reward nor weight.

The second proposal (the one he likes better) is about adding rsa weight to coin weight and I written on many places that ADDING anything to the weight has the multiplication flaw. The added weight is automatically multiplied by the number of mature UTXOs.

The first proposal does not have this issue as it multiplies the weights. But I don't understand the equation to calculate new rsa weight.

NEW_WEIGHT = (owed + Magnitude)/Magnitude
TheCharlatan commented 7 years ago

I wrote a proposal for a new beacon registration process, it was added in the wiki as another chapter. It improves on the decentralization of the procedure and enables the transfer of a CPID from one wallet to another by using 1of2 and 2of2 multisig and a known beacon address and key.

tomasbrod commented 6 years ago

A little addition: StakeMiner article

tomasbrod commented 6 years ago

I split off the following articles:

tomasbrod commented 6 years ago