I have recently got into the habit of manually voting on NNS proposals every alternate day. I also only follow the Dfinity and ICA neurons.
So, if a proposal has the proposer as 39 or 40 and is not a governance topic, i usually press “adopt” without too much concern. However, for other proposers, I tend to read the submitted abstract to see what the proposal is about.
Being an interwebs citizen for the last 15 years, my scam detector is kinda tuned at this point to detect warning signs. This particular proposal caught my eye as it has all the hallmarks of being scammy.
They are:
not being from the official source (expect proposer to be 39 or 40)
Alright, on some further investigation, it seems this proposer has submitted other valid proposals that have gone through.
So, probably, someone from the Dfinity team? Also, a recent submitter. Their history shows that their first proposal submission was on the 2nd of this month
@lastmjs that’s a valid point, we (nns team) are trying to be more transparent about releases including more information in the summary. We’re putting together instructions on how anyone can verify the build, but they will likely depend on docker. Would it be valuable to add these instructions to the proposal summary itself?
Anybody can reproduce the wasm hash listed in the proposal by following the steps in the repository readme https://github.com/dfinity/ic#building-the-code. This gives you certainty that the wasm reflects to the open source code. I always do this check myself.
Ah I now see that this proposal does not properly render the payload in the NNS dapp, that’s a big problem, thanks for pointing that out!
You can see the payload on the dashboard: Internet Computer Network Status, and of course the NNS dapp should show the same payload, but apparently there is a bug there. I’m sure this will be fixed soon.
At least on the dashboard, you can see the proposal contents, and see the git hash (ed721ffdde4b1d4d982d0c843a0b9e293380e05b) and wasm hash (3cc60f5bee9f555258a5bfb648ff16e7441bc4920383c1127c9bd564eccfc848). To verify that this wasm hash makes sense, you can check out the source code https://github.com/dfinity/ic at the specified commit hash.
So now I am personally convinced that proposal indeed proposes to update the registry canister to a wasm that was built from commit hash ed721ffdde4b1d4d982d0c843a0b9e293380e05b of https://github.com/dfinity/ic. You can follow the same steps and convince yourself too :).
This is a thought for later down the road probably, but I’m thinking it would be nice to have multiple independent parties check off on important proposals. For example, imagine if we could create a data structure known as a committee. The committee could have special power given to it from the community to merge certain proposals. Each committee would have known independent parties inside of it.
3 independent committees would need to pass off on certain proposals.
Just an idea. I just don’t like the idea of pure liquid democracy updating core canisters, if someone isn’t watching bad things could happen.
For those following this thread, we made another proposal to upgrade the registry. This time with a better laid out commit log and with instructions on how to build. It’s here: Internet Computer Network Status please take a look and let us know whether you can see any further improvements.
