By pushing password hashes to the client you'd be exposing them to offline brute force attacks. That can be entirely acceptable if the passwords are sufficiently strong. But that is a dangerous assumption to make.
You could ask each user to confirm that they want their own hash to be published (after explaining the risk to them). But there is a lot of users who would happily say they understand the risk and have chosen a sufficiently strong password even though what they actually choose was
At this point you will have to evaluate how important this feature is compared to the risk from allowing the users to shoot themselves in the foot.
There is however another drawback in your design which is that of authenticating the updates made offline. Relying on the client to validate the user is not good enough.
Storing the user's password together with the update and sending both to the server once online would address the problem of performing only client side validation. But you would introduce three new problems:
- It would not catch mistyped credentials when entering updates. And later when those credentials are verified by the server, the user who typed them in the first place may not be around to fix that issue.
- The update would be malleable. It would be trivial to modify the update while stored on the client device to make it perform a different update once it arrives on the server.
- You would be storing passwords in plaintext on the device which is a big no-no securitywise.
I don't see any way to prevent offline brute force of passwords while still allowing the password to be validated at the time where an update is entered, and that validation is necessary for usability reasons.
The approach I would thus take is to create a public key pair based on the users password and a salt, and use the corresponding private key to sign the update. That means the update is no longer malleable, and the password need not be stored and transmitted, rather you just store and transmit the signature.
Of course the client would still need to know salt and username to generate a properly signed transaction. And it would need to know either the public key or a hash to verify it in the first place, which allows for offline brute force attacks.
You can truncate the hash verified client side to only a single byte, which makes offline brute force attacks less feasible and still has 99% chance of detecting incorrect passwords on the client side.
On the server side you should still be verifying the transmitted public key using a salted hash to ensure you only receive valid transactions.
Obviously any design for the application you are designing leaves lots of room for mistakes, so having final design and code reviewed by multiple security professionals is a necessity to ensure that the final result is secure.