Right forget the github link it is not needed. But would having only a single hash make the coin a bit centralized? Would the architecture allow multiple simultaneous hashes per version from different developers who compiled in different languages? Who gets to control the official hash released into the blockchain, and wouldn’t that part of the process be centralized? This is a gigantic hole in the crypto space, untrusted code is ripe for viral infections. Reminds me of bit torrent how any exe you download from there definitely has some trojan in it. Eventually the whole crypto space can become a toxic infested wasteland like bit torrent 
I dont even like updating my software wallets because its a gamble every time: does the old version have a bug vs. does the new version have a trojan.
If the nodes aren’t capable of handling the current consensus versionn they won’t sync. The consensus version is included in every single proposed block and there’s a formal mechanism on-chain for how new consensus versions are voted on/accepted. If a node was altered in some way to vote differently, etc. then that’s just a plain malicious/hacked node.
Version is just a number, seems we need a hash to be sure.
It’s just a string representing the consensus version the code understands. That’s it…
from goal node status:
Last consensus protocol: https://github.com/algorandfoundation/specs/tree/3a83c4c743f8b17adfd73944b4319c25722a6782
Next consensus protocol: https://github.com/algorandfoundation/specs/tree/3a83c4c743f8b17adfd73944b4319c25722a6782
That’s in each block - so when there are ‘new’ versions there’s a process to certify it before all the nodes ‘switch’ to the new version.
Independently, the hashes that matter are in the blocks themselves. If the nodes aren’t synced properly In the first place, they’ll never accept new blocks from other proposers as the hashes won’t be correct.
The blocks, whether through a fast-catchup (which still has to fetch new blocks beyond the every 10k block ‘catchpoint’) still have to be individually fetched and the hash chain all has to be correct.
Following what @aojjazz wrote, everything is strongly linked together using signatures and hashes.
In most cases, the signature(s) that you’ll find in a block are over a hash of the proposal, which is, in turn contains a hash of the block header, which contains a hash of the transactions.
The block header, naturally, contains the hash of the previous block header.
You’re welcome to try and break it… and, in fact - there is a bug bounty program for that as well.
( needless to say, it needs to be a concrete viable issue )
We are not talking about versions here. We are not talking about nodes that are outdated. What you are talking about is an internal mechanism which valid nodes use to make sure they are using the right version of consensus algorithm.
We are talking about a node software that is designed by an adversary to attack the consensus protocol.
There is absoulutley no way for preventing a malicious node from voting in the consensus.
Unbreakable perhaps at the cost of some centralization it seems. I’m talking about decentralized Deterministic/Reproducible builds. Is Algorand currently a Deterministic/Reproducible build? If it is that hash can be kept on chain in the form of a signature by the publisher. This way we can trust the published code. If its not deterministic it’s for little kids. But hey i’ll be a little kid too we all need to make money with speculation.
Well… This is really a good point and I think you are right. Having those hashes in block headers is not a good idea. It could prevent the independent implementations of the protocol.
Maybe a better idea could be that the official developers of any software sign the hashes of their software and put it on blockchain like a transaction. This will also give nodes a way to update themselves securely. For example, my node will update itself only when it sees the special “update transaction” from Algorand foundation on the blockchain. This transaction also gives my node the download link and the hash of the new patch that should be applied.
Brilliant! This is how all coins should work by default! I’m not aware of any that do this… maybe the closest resemblance is Tezos, I’m not sure.
I believe that the current approach is that the protocol version ( which is a string ) points to a repository that describes the details of the protocol implementation ( i.e. pdfs ) . Any implementation of that said protocol should be able to join the network.
Note that different builds would have different hashes ( i.e. compile for windows vs. compiler for linux ).
I’m also not sure if the binary of a compiled binary is guaranteed to be bit-repeatable on consecutive builds. ( It wasn’t the case when a checked a .NET build a decade ago… might have changed since ).
That’s not necessarily a bad idea, but could discourage other engineers trying to developer a better node implementation.
This is exactly what I was talking about, Deterministic/Reproducible builds. Algorand must be bit-repeatable on every build to be taken 100% serious in the community.
You’re discussing specific compiler toolchain issues, having nothing to do whatsoever with Algorand, nor nodes, nor consensus mechanisms. It’s very common for things like timestamps to be embedded in builds as part of build tooling, fetch locations specific to local infra (internal mirrors for dependencies for eg) and any number of things which will alter builds from build site build site. For a given build instance and depending on the version of Go (in Algorand’s case), then it should produce identical builds from consecutive runs assuming the exact version of Go was used for the exact target, exact architecture, exact dependency set, etc.
Obviously Windows builds will differ from OS X builds which will differ from Linux builds not to mention CPU targets.
ALL are equal participants in consensus and none will have matching binaries. Multiple toolchains have multiple implementations of their nodes. Ethereum lists no less than 5 completely independent implementations (Nodes and clients | ethereum.org).
Anyone can write a new bitcoin client for eg, or a new client for basically any blockchain. They have to follow the rules of the protocol and consensus and if they’re not - they’re malicious. Proposing a block or voting on a block that doesn’t fit ALL the correct criteria will be ignored by all honest nodes. Some aspects of that are basically ‘inconceivable’ to ‘fake’. There are numerous ways of being malicious though, but this is all foundational to a proof of stake chain. There’s a requirement of a certain percentage of honest actors - just like there’s a requirement in Bitcoin that someone doesn’t control more than 50% of the hash power.
Some would argue NOT having other implementations of the nodes is itself a centralization issue and one which Algorand themselves brought up in a recent office hours session. Having alternative implementations of an Algorand node would be a good thing actually. I’m a huge fan of Go, so I’m just fine with the current node code. 
Either way, I fail to see how this is remotely an issue. In fact, it’s not even feasible. It seems as if you’re implying there can only be one node binary allowed for everyone to run, around the world. That’s not how blockchains work.
Numerous versions are online at the same time with various patches. Short of hard consensus changes that ‘force’ upgrades, the versions will be quite varied depending on upgrade/maintenance cycles of the runners.
If you have references to chains and clients that you think do what you think is ‘correct’ - I’m curious what you find that to be.
I think every open source software that also has binary releases should be like that. Otherwise there will be no guarantee that those binaries are really built from that source code.
Integrity checking of software is not something new. For example, in windows all .exe files should have a digital signature attached to them, otherwise, the OS will display a warning when the user wants to execute them. That digital signature is a cryptographic safe hash of that file (usually sha256) signed by developer’s private key. Using those certificates requires trusting in certificate authorities like digicert, comodo, etc. In the blockchain community we are a bit paranoid 
and we can’t trust them. So we were discussing ways that blockchain could be itself used for integrity checking of node’s software,
The integrity of node software (i.e. protocol implementation) is an issue in all blockchain, but in Algorand is more important because all nodes are validators (i.e. miners).
You are right. That’s why I changed my mind:
Still, its a good idea if developers send hashes of their software as normal transactions to the blockchain. Though, people would still need to verify that the sender account of that transacton really belongs to official developers.
Also, this method will enable existing valid software to update itself safely.
The same thing applies for catch-point files. Instead of having their label on amazon servers, foundation could send them on blockchain as transactions. This way we won’t need to trust amazon servers
Sure - but that wasn’t what you were asking for. 
If you’re saying you’d like Algorand’s binaries to be digitally signed, then ask that. Personally, I tend to build the node I run, myself, from source.
I don’t see how this addresses anything though. A malicious node would just send a ‘known good’ hash regardless of the code it was executing. You’re asking for a trust-based enforcement policy to verify the validity of good actors in a system you’re trying to protect from malicious actors. The malicious actors will just change the code to send what they want.
It’s not a bad idea, but who decides to put it there in the first place? Now you’re trusting whichever node put it there. It could be part of the proposal system - every 10k blocks, a block can contain a catchpoint commitment field and the nodes vote on that block proposal like any other. It could certainly be used as an additional sanity check.
I think @tsachi’s point early on with all of these things is that there’s always going to be some level of trust, particularly in bootstrapping. I think a fair start would be the process which updates that s3 bucket with the catchpoints to be really clear so other companies or users could publish the same thing in different places (ipfs, etc.) and people could verify they matched on multiple sites. The catchpoint command just takes that block # and hash - it can come from anywhere [on purpose].
Well… this is what I was suggesting in my previous posts:
But in my last post I was trying to say something else. I was trying to say that blockchain could be used as a secure way for broadcasting/publishing information, specially if we had something like Ethereum’s ENS. suppose that ur wallet’s address was ‘aojjazz’ instead of a complex hash. then u could use transactions as a way for publishing information. for example if u issued a transaction with text ‘I love GO’ then any one could be sure that ‘aojjazz’ had said that and also u could never deny saying it. unfortunately we don’t have something like ENS on Algorand. but still we can use this feature of blockchain to some extent.
so I suggested that Algorand could use blockchain for publishing cachpoint labels instead of github or amazon servers.
Also developers can use blockchain as a way for publishing the correct hash of their code. and users could use those hashes to verify they have a genuine software. I didn’t say that a code can check its own integrity with blockchain or something like that. this is not possible. but a software can use blockchain as a way for securely updating itself.