Listen to the "reproducible hashes" feedback. Think of it as a "super-md5" of a directory instead of a single file. However it is done, the output should be de

Listen to the "reproducible hashes" feedback. Think of it as a "super-md5" of a directory instead of a single file. However it is done, the output should be deterministic by default, with "controllably underterministic" as an advanced choice. Use case, especially with the suggestion of sub-file BLAKE3 inclusion validation: Continual random file validation for backups. Assume you "sign" your hard drive, or your home directory or something as part of your backup process. Ship bits willy-nilly to anywhere, and be able to request an arbitrary subset / sub-block of any file to compare to the local disk. Instead of making me download a 1GB file from you to compare SHA's and ensure it isn't corrupted... I challenge you to return to me the SHA of an arbitrary byte range from within that file. Assuming we both have the original bits on a disk somewhere, it's an easy task. Basically you're trying to prevent replay attacks where the upload-receiver accepts the file, "cheats" by just saving the SHA, and responding (replay) with the SHA from when it was uploaded. Forcing "proof" that they "could" return an arbitrary range of the file is "proof" that they still hold the "whole" file. The unique "game playing" that you're doing here is "proving" that you can reproduce a portion of a directory on demand. The value is then being able to validly demand (as the original file-holder) a subset of your data from a third party. "I prove that I have all this... I gave something from within there to you... now please prove to me that you can give it back (prove that you in fact received it)"