Hash type too inflexible #6

The current design has the hash in the setup package stored as a plain byte 
array. I presume that the plan is to support longer hashes in the future by 
checking the length of the array, but this has one major flaw.

Presume that a SHA-3 algorithm is selected. It will likely be reccommended for 
widespread use shortly thereafter. If a subsequent flaw is found, any 
replacement chosen or tweaks applied will keep the API invariant, *including* 
the digest length. The versioning inherent in protocol buffers will not help 
because the current protocol is insufficiently self-descriptive and has 
unwarranted assumptions. I would suggest including some sort of identifier of 
which hash is in use.