Future of the Tree-SHA512 once everyone has upgraded GIT. #15578

Git is transitioning to use secure 256bit hashes internally and for commit/tag/blob references. Because of the uncertainty with SHA-1, a SHA512 Tree was added to each merge-commit message; and a automatic script was written for maintainers that verifies the tree-hash's integrity.

The development community of git maintain a document detailing their progress in addressing original design constraint of hard-coding SHA-1, and migrating to SHA-256:

https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.txt

It is not expected that this migration will be completed with great urgency; (unless more serious breakages of SHA-1 are published).

Furthermore, the usage of the tree-sha512 hash within the Bitcoin Git commit history has the advantage of helping detect any software or other problems within git.

Longer-term goals: Extract the tree-sha512 algorithms, and create a separate project for it's maintenance and support. Maybe a seperate project for the Bitcoin Github Merge script: https://github.com/bitcoin/bitcoin/blob/master/contrib/devtools/github-merge.py

Once git (and other infrastructure we rely on, like github) properly support a better hashing mechanism I expect we'll just drop the tree-SHA512 hack. Or not, maintaining is very low cost, while extracting it into a separate project seems overkill.

I think the best workaround for now is to sign your commits (or at least the top commit of each branch you submit). That should prevent an adversary from grinding a conflicting commit id.

We already do that in github-merge.py, so the sha512 hash is mostly calculated for fun, I believe.

Yes, it's a stopgap measure, once it's no longer needed, I'd be happy to drop it.

Or not, maintaining is very low cost

It's very fast to compute on merges. Verifying it deeper like the verify-commits script does is fairly expensive, dropping that could save some Travis time.

extracting it into a separate project seems overkill

Some other projects already use bitcoin's github-merge.py script. Maintaining it as a separate project indeed seems overkill, and is not something I'd consider, though someone that wishes to do this can of course do so.