The two SHA256 sums printed above from a) the downloaded CDN image and b) the locally built image, must be identical, and must match the SHA256 from the payload of the NNS proposal.
The two SHA256 sums printed above from a) the downloaded CDN image and b) the locally built image, must be identical, and must match the SHA256 from the payload of the NNS proposal.
For proposal 131054, the referenced git revision (a3831c87440df4821b435050c8a8fcb3745d86f6) doesnât seem to belong to the IC repo.
^ this is what Github displays (I think this indicates that the branch has since been deleted).
If I try to fetch all changes and then search for this commit (a3831c87440df4821b435050c8a8fcb3745d86f6) itâs not found.
Based on the git graph and the revision for proposal 131055, it looks like the correct git revision for proposal 131054 would normally be 6135fdc (but that wouldnât include âRevert âfeat: RUN-842: Switch to compiler sandbox for compilationââ)
Given the current circumstances Iâd be inclined to reject proposal 131054.
@Lorimer seems to have been an issue with the gitlab â github sync (and migration). This issue should be fixed now, please try again. I manually pushed the branch, although this was supposed to be done automatically
Thanks @sat, much appreciated, thatâs addressed it
Given that the commit hasnât been available externally until now, itâs concerning how popular the âyesâ vote has been so far (how did they verify the build?!)
Recently, the Rakeoff named neuron has been set to follow krzysztof.
Is there an expectation to verify these esoteric IC releases? In an ideal world you could say yes. But realistically do you expect named neurons to verify all of these? Isnât that what the âfollowâ functionality is for.
If youâre actively voting âyesâ (rather than following someone elseâs vote that you trust - as in your case), then absolutely yes. Itâs extremely dangerous (particularly moving into the future) to vote blindly on technical proposals that modify the protocol.
But realistically do you expect named neurons to verify all of these?
No, in the same way that all named neurons are not expected to actively vote on all proposals. Yes, I agree that this is what following is for (passively voting, by actively choosing who you allocate your voting power to). Given that Rakeoff is a liquid staking protocol, the choice of followee is extremely important (assuming the voting power of any number of stakers is in play - not just now but in the future).
Can I ask why you chose Krzysztof for Rakeoff to follow (what selection criteria were you using that were met by this named neuron)?
@krzysztofzelazko, looks like it falls to you. Are you able to explain your vote?
I wouldnât give krzysztof a hard time about this, seems like your trying to put some public scrutiny on something I wouldnât consider that important. It was a proposal submitted by Dfinity for an IC release . Frankly, whatâs the big deal here?
It looks it was verifiable later and all was fine anyway? Should we be expecting Dfinity to be publishing malicious code to the NNS?
IC-OS proposals have the potential to cause untold damage if a nefarious proposal slips through the net. Why would you consider this to not be important?
It was a proposal submitted by Dfinity for an IC release . Frankly, whatâs the big deal here?
Why do you think a great deal of effort has been put into the design of the NNS, reproducible builds, and governance decentralisation initiatives - do you think all of that is pointless?
It looks it was verifiable later and all was fine anyway?
If Iâm confident in my ability to hold my drink, so I down a few pints of Guinness and then hop in my car to pick up some food, does it make it all okay that I managed to get home without a scratch (no harm no foul) - at least I got my food? Or did I roll the dice and do something unjustifiable?
Should we be expecting Dfinity to be publishing malicious code to the NNS?
Honestly I think comparing voting yes without verifying IC-OS releases to drinking and driving to be unjustifiable. I canât really see how that is an appropriate analogy to use here.
Besides that, I know these are important proposals, however I was saying that if a named neuron (such as krzysztofâs) looks at an esoteric proposal about an IC-OS release from what appears to be Dfinity and votes yes on it - I donât think they should be held to public scrutiny and have to explain their vote.
Maybe you want to hold named neurons to a really high standard. That is probably an argument against named neurons then as a whole and you could start a thread and discuss that.
@Lorimer correct me if iâm wrong but you are apart of the CodeGov team? So you get paid to verify these?
I think itâs important to remember most named neurons are not paid to verify these and are just doing the best they can and receive the normal staking rewards for doing so.
Honestly I think comparing voting yes without verifying IC-OS releases to drinking and driving to be unjustifiable
Both are examples of âno harm no foulâ mentality, and an âappeal to consequencesâ logical fallacy. If you agree that one action is wrong despite the absence of consequences in a specific scenario (e.g. drink driving) then it begs an explanation for why another âno harm no foulâ scenario (blindly voting âyesâ on a proposal that could bring down the IC, but didnât) is justifiable on that basis.
I donât think they should be held to public scrutiny and have to explain their vote
Named neurons have gone out of their way to advertise themselves as voters to be followed. Iâm inviting Krzysztof to explain what happened here (Iâm not assuming that thereâs not a justification). Iâm sure heâs perfectly capable of defending his position himself, or holding his hands up, and reassuring potential followers about how future proposals will be tackled.
you could start a thread and discuss that
If you think that would be useful, I may take a look at doing so at some point.
correct me if iâm wrong but you are apart of the CodeGov team? So you get paid to verify these?
Yes.
I think itâs important to remember most named neurons are not paid to verify these and are just doing the best they can and receive the normal staking rewards for doing so.
This is unlikely to be the case moving forward.
In any case, I donât see your point. If youâre not going to verify a proposal before voting âyesâ, youâre acting irresponsibly. This is the use case that liquid democracy accommodates - so why not use it properly (follow those who put the work in and verify proposals, and even review the code - Krzysztof could simply follow a neuron that claims to do / evidences this)?
FYI @DRE-Team, similar to a few weeks ago, the âChangelog since git revisionâ reference for proposal 131055 (above) is incorrect - at least as I understand it.
Proposal 131055 stems from commit 6135fdc (highlighted in the git graph illustration above), not a3831c8 which is actually a future commit with respect to the head 131055 proposal commit (0d2b396) and is also on a separate branch (illustrated in the git graph above).
This proposal summary claims to be making a change but then reverts that change in the same proposal (so itâs not actually making that change at all). I think it would be a lot cleaner and easier for voters to follow if these sorts of commits are omitted from the proposal summary altogether (provided the reversion commit is an exact reversion).
@nikolay.komarevskiy are you able to provide more information about why latency based routing is being disabled by default. This would seem to be a useful feature. Could you explain the scenarios where this would be undesirable (and why these represent the default case)? Thanks in advance.
this is quite unique case that we didnât have before so itâs not supported in our tooling and therefore kinda a mistake. we discussed this previously that a case like this might happen and were not sure if it makes sense to say something like âchange since this commitâ if the commit is not actually a tip of some release that was blessed before. I think in this specific case, we would want to say something like âchange since commit 6135fdc (first introduced in release a3831c8)â
Thanks for your response @Luka. Do you think it could be worth displaying these types of scenarios slightly differently, rather than including a reverted change in a list of changes to be applied?
I like your suggestion for how to display the âchange sinceâ commit. I think that would be very helpful.
we can change the formatting if you have some idea. it would just be beneficial to maintain both commits in the changelog for transparency. a thing to note, this is not such a common scenario either. iâm pretty sure itâs first time in 3 years that we had such a weird case.
Thanks in advance.