According to this report : http://www.ecrypt.eu.org/csa/documents/D5.4-FinalAlgKeySizeProt.pdf
SHA2-512, SHA3-512, Whirlpool and Blake2b are hash functions that could be safe for the next 50 years.
For a system that will never receive security updates, to hash passwords, what of these 4 functions should I use for maximum security ?
None. Cryptographic hashes are not directly suitable to store password hashes.
You should use a password hash (also known as a Password Based Key Derivation Function or PBKDF if it is used to derive a key) such as one of the secure variants of Argon2 to store passwords, not a generic cryptographically secure hash function.
However, if you're working with passwords then not updating your security for 50 years is madness; there is a lot of debate on the security of passwords as it is. Passwords generally only deliver a certain amount of security, often in the range 30-50 bits. That already doesn't provide enough entropy, let alone in 50 years time.
Password hashes add a work factor, but in 50 years this work factor may well have become insignificant due to progress in chip manufacturing. So the additional work factor (e.g. introduced by an iteration count) has become a much smaller hurdle to take. Note that finding passwords is an easily parallelized task, so it is not very dependent on single core CPU speeds.
You could also go for 128 or even 256 bits of security and let people write down a randomly generated password / key instead (for instance as 32 / 64 hexadecimal digits). That way you could use a simple hash just to hide the password / key at rest. For this you could use one of the hash algorithms above; I'd go for SHA-3. However, due to the larger password, your password management becomes more complicated as humans will probably not be able to remember it.
This can be solved by having people use a password manager that is secured with an easy to remember / less complex password or phrase. Such a password manager should then be directly available to hackers. Another advantage of using a password manager is that the passwords can be updated if a password has possibly become vulnerable in any way.
Similarly you could encrypt with e.g. a large EC public key and protect the private key of the key pair. However, most common asymmetric algorithms are vulnerable against quantum computers. Those could well become large and interconnected enough in the next 50 years. Post Quantum Cryptography is by and large still the domain of specialists (even more than common modern crypto).
As Maarten writes you should use specialized password hashing algorithms and not generic hash functions.
But I would like to discuss the futility of planning for 50 years into the future. It's really impossible to know what the future so far ahead has in store for us. There could be all kind of changes we can't even imagine now.
Nevertheless our best bet for what will change in 50 years, is to look back 50 years ago. In the last 50 years everything changed. Cryptography was reinvented. We didn't even have DES 50 years ago, let alone anything we consider secure. We didn't salt passwords, we didn't have memory hard functions or side channel attacks or anything we consider essential now.
The oldest password hashing which gives some security is probably the unix crypt based on DES; it had a salt and iterations to slow it down. But it only supported 8 byte passwords, couldn't tune the iteration count, and had small salt. And that was 40 years ago.
Perhaps cryptography will plateau and our best crypto of today will hold. But I won't give you very good odds for that.
We may find specific weaknesses in whatever you chose, we may find broad new generic attacks. We may discover there are no one-way functions at all.
Planning crypto for 50 years in the future is a futile exercise.
