Technically speaking, I vote “Do not apply …”
But I totally agree with BostonMike
I would not completely close this question.
I would give the guys time until the hard fork really needs other targets…
1 Like
I am quite mixed on this, and tend to agree with Boston Mike, and also Fible.
I am generally in favor of sticking to what we all agreed to, and don’t like changing the rules retroactively. That could go both ways if we indicate a willingness to do whatever the community “feels like” with the agreements, it will be difficult (for me at least) to trust us to honor our agreements in the future.
That said, although I know what the agreement was, I was never, and most likely never will be, in support of anyone messing with account balances via a fork. (Perhaps major events like significant bugs+theft aside.) I think action like that demonstrates an even worse trust-breaking feature of the community.
Whether the policy changes or not, as a block producer, I would advocate for an “unofficial” fork that does -not- alter balances.
So I voted for leniency - not because I think leniency is appropriate - but because the alternative of balance manipulation seems much worse.
Another potential solution would be to alter the “canonical” requirement. If running solo and you generate and broadcast a block, I think that should have counted in the original scheme. It is out of your control as a BP if you are unlucky and product non-canonical blocks. I have not looked at the data, but this may be a better solution that honors/values independent block production. (I know there are still software issues that may even fail/complicate this solution, so perhaps the solution proposed is the best use of resources……hence my vote.)
Another solution that is more foolproof has been suggested by Emre. I am not sure how easy/possible that will be to run for the entire year. If the software exists for this 6 to run, this seems like the most “honest” approach to prove good faith attempts.
All of that said, even if the alternative methods prove less-than-“honest” results, I am opposed to manipulation of the ledger for this purpose, period.
5 Likes
They who try to delegate hv also make their effort to not meet the provoke mechanism as when they try to run a validator, they don’t get that luck (to make a single block), because of they lose probability from the big pool,
They (the GFM Delegator), hv make their effort to run a pool and try their luck first and then make another effort to delegate to a big pool so they can meet a point to prevent the provoke mechanism
1 Like
In the beginning I decided to delegate for similar reasons Boston Mike gave. My technical abilities and in general my tech, extremely slow Internet and imperfect setup, left me feeling insecure about jumping into running a node out the gate. So, I’m continuing to delegate for now with the hopes of block producing during year 2 and so on. I appreciate the dad point of view and ice cream analogy. Is there a way to engage with the 6 folks and see what the issue is? Is it truly a technical issue or non participation? If they are really not participating then maybe there is a need for some type of recourse. However, I am not really in favor of hard forks unless absolutely necessary.
1 Like
I voted for “not enforce” this year because of random nature of VRF so in theory some validators could’ve produced less blocks than others. However, if it’s gonna be a case next year I will definitely vote for “enforce”.
Moreover, I believe it makes perfect sense to account for non-canonical blocks too because in this case meeting the requirement will not be related with any luck.
1 Like
I agree with jrwashburn explanation.
In completion to everything that was said:
Interfering with the blockchain through a hard fork in order to alter the balances of a nominated number of keys is damaging and irreversible for the spirit of decentralization, crypto and not ultimately Mina.
Later edit, what I mean: Interfering with the blockchain to enforce an off-chain agreement with almost no stake and potential technical and reputational issues is not a good idea.
1 Like
I’m in favour of not enforcing the mechanism and allowing the affected accounts to keep their grant.
Almost all GFMs have met their obligations and for the very small minority that have not (<1%) a hard fork seems heavy handed and doesn’t set a great precedent. All of the GFM put in a huge amount of effort during the testnets and allowing them to keep their grants is in keeping with the MINA community values.
2 Likes
I wasn’t a genesis member, but if I was I would be chapped that this is even being brought up. Why have rules and requirements if you are just going to bend them for some people.
Why not issue 66000 mina to ever block producer now?
2 Likes
I have mixed feelings with this, but seeing that it is just 6 GFM that failed to do so, and probably we do not fully understand / know the reasons behind it, I wouldn’t mess up the ledger if no extreme reasons like technical problems or theft are playing a role.
1 Like
In fact, compliance with the rules is very important, otherwise why are they then?! But…
It seems to me a good option was proposed by EmreNOP, so that these 6 people provide the VRF outputs, and if this is due to contingency, then I would leave everything as it is and not change the ledger. My vote is for this option.
1 Like
I do believe one has the need to ‘do the work’; however, with this being the first year - I think some amount of grace is proper. Since there’s so few that would be affected, and some sharing out here - perhaps outreach to the others would be useful?
In fact, I think having a buddy system might be something that emerges from all this. I know I’d like to have a buddy drop me a note if they noticed something amiss on my machines and such. Don’t know how this would look like.
1 Like
I think the idea of a buddy system is a great suggestion but difficult logistically. Maybe make it a community responsibility of highlighting any problems seen with any machines?
1 Like
I’m just running an update on the script for the latest epochs and I checked the 5 producers who have had no activity (6 keys haven’t met the criteria). Two of them look like invalid public keys. Here’s the output from the daemon for B62qqdcf6K9HyBSaxqH5JVFJkc1SUEe1VzDc5kYZFQZXWSQyGHoino1 and B62qpyhbvLobnd4Mb52vP7LPFAasb2S6Qphq8h5VV8Sq1m7VNK1VZcW. These are both in the ledger still.
mina client get-balance -public-key B62qpyhbvLobnd4Mb52vP7LPFAasb2S6Qphq8h5VV8Sq1m7VNK1VZcW
Error parsing command line. Run with -help for usage information.
Couldn't read public key
(Failure
"Compressed public key \"B62qpyhbvLobnd4Mb52vP7LPFAasb2S6Qphq8h5VV8Sq1m7VNK1VZcW\" could not be decompressed")
So let’s assume those keys are invalid, so that leaves 4…
One is this key B62qowREyBtVMpp8RVkbmfvZgxryNUzcJnRnH9LRs5xgAXkHhLyBEyz that is now very close and has produced 94 blocks with the help of a delegation. They just started very late (first block end of October) and will probably meet it?
That leaves 3 unaccounted for. One is this key B62qqiV28EmAXco2BuXoL4wSz3UHCv7zG387FnqYoiCkwNJWRywJ3KQ which tracks to user ansonlau on Discord. Here is their post but that key was generated via the outdated keygen tool and so inaccessible.
Down to 2. One of these two is known to be unable to access their keys so that would leave the OP as the last key, so assuming they are and can delegate…
2 Likes
I don’t think this situation deserves a hard fork. This is not systemic idleness, but just a few accidents (as Gareth said). Changing the rules retroactively will severely erode trust. For a hard fork, you need some more serious situation.
1 Like
There is a hardfork coming up for SNAPPs anyway, and this post is just to discuss whether to include this in it.
1 Like
I totally agree 
1 Like
No need for a hardfork , and as Gareth shows we are talking only two accounts
1 Like
Hey Everyone, really good info, conversation and debate in this thread. Let’s give this decision another week for folks to vote and also give some time for folks who havent been involved yet to participate. So let’s close the poll on Friday, 20 January at 18:00 UTC and go with the community consensus reflected in the poll on this thread as the final decision. The Mina Foundation Community Team are circulating this message on all of the community channels so everyone is notified and has the opportunity to participate.
1 Like
I updated the script for the current epoch Calculates whether GFM has met staking criteria · GitHub so B62qowREyBtVMpp8RVkbmfvZgxryNUzcJnRnH9LRs5xgAXkHhLyBEyz has now met the criteria 
so at most we are discussing 5 addresses.
Realistically it’s these two addresses as the others are all known to be inaccessible (2 provably via the client, 1 via Discord due to old keygen tool). Notably all 5 have no activity at all.
B62qpmq5XCNpv12G125tnrGtcJJnMD5qEQ8Riw9LLEtjxAQ1wNjywYm
B62qq9WWQBH8Zy6uHEfQakYGRcCAruHRdaQU597WFR5qf5T99Cab3rE
As I eluded to above, one of these is known via offline sources to not be able to access their keys. If the other one is the OP, it would be curious if they still haven’t delegated.
2 Likes
FYI this isn’t changing the rules. It’s applying the terms that were agreed to when the grants were given.
2 Likes