upcoming changes in Gridcoin (e.g. effects on less rich users; fixes on (known) exploits)

[erkan]

One of the next (mandatory) releases will include this new:

• Gridcoin PoS kernel v8

One of the changes there will be:

• "most notable effect is that magnitude does no longer affect your stake weight. Investors and BOINCers now have the same chances to mint a block. This drastic change was needed to eliminate an exploit. On the other hand a compensation for less rich BOINCers is already being designed."
• Thus, it seems, one of the recommendations for less rich BOINCers appears to be to stay in a Gridcoin pool

See the Gridcoin milestones also here:

Other upcoming changes are to fix:

• ability to exfiltrate user's email addresses (used also in BOINC) from the Gridcoin blockchain
• hijacking beacons (stealing an user's CPID registration)

Read more at:

• under investigation: security issues in Gridcoin

When these and others fixes really do come ("scheduled for NN2.0 or right before it") I'll keep you updated on.

originally posted here

Comments

[dutch]

hijacking beacons (stealing an user's CPID registration)

For the love of everything, can we have less of these tiny FUD sentences with no explanation? For example, this specific item was discussed between Rob and Martin in the dev channel on Slack, and Martin conceded it is not possible anymore due to automatic beacon renewal 2 weeks before expiry. Further, the network will prefer the older keys over a newer set.

This drastic change was needed to eliminate an exploit.

Which was?

[grider123]

Good point. But as far as I remember Rob has written that the client always prefers the newest matching keypair ;)

[dutch]

If that were the case, I could take any CPID I wanted from anyone else. Get their email from the blockchain, get their CPID from any of a number of sources, use them to request a new keypair by sending a beacon and I own the CPID.

[grider123]

I just copied from chat:

So on his second exploit he said that he can lock out a researcher, if he writes a program to create a beacon right after the beacon is about to expire. We do have a line of code in the system that Prefers the existing keypair IF the client refreshes their own keypair (as it would be impossible for the attacker to sign a NEW message with the existing keypair) first. So to cave on our 'feature' to allow beacon deletion, we sort of have this exploit, but the client constantly checks once every 4 hours if its beacon is about to expire and tries to refresh it. Now that I remember a little more about this exploit, we added code TO PROD, that refreshes a beacon 2 WEEKS before it expires to try to prevent this. We always prefer the newest Matching keypair, so that does invalidate this hack also.
At least it makes me say - Technically this paper is no longer accurate.

[personthingman2]

Can we get a more in-depth explanation as to why removing magnitude from the stake weight calculation was necessary? And possible solutions for compensations that are currently under discussion?

[erkan]

the 3.6.0.1 version will enable this stake-v8 at block 1010000

• see here

[kuradikurat]

Sad news...
GRC is already known as a "whale coin" and now comes this?!