This is an idea for implementing a short-form unique identifier style string that is composed from a substring of the SHA 256 summary for your crypto art NFT media as part of an enhanced artist’s signature metadata.
Why should I hash my art media?
Simple, doing so provides an additional layer of difficultly disputable proof that the media connected to the token is indeed the valid media that you, the artist intended to represent through the token.
If you retrieve the summary from the final media file (via various freely-available tools for all operating systems, listed in the resources section), you have a literal digital fingerprint of the file that cannot be easily forged with today’s computing capabilities.
Including this string in your “signature” as part of the token metadata is a great way to prove the correct media for your token.
What is SHA 256?
Briefly, it is the 256 bit mode of the SHA-2 hash algorithm. A hash algorithm can create a one-way representation (i.e. cannot in theory be reversed or altered), similar to a fingerprint or signature of any file, including your crypto art media files.
SHA 256 just happens to be one of the most popular of such algorithms. You could also use any other hash algorithm for this purpose and apply the same shortening technique to it.
So what’s hard about just using the full SHA 256 summary string? Normally the SHA 256 summary is a string of 64 alphanumeric characters that looks like this.
Using such a long string as part of your art’s description on crypto art platforms is not ideal, as some of the platforms will not display the string completely or properly due to wrapping issues and other web design constraints.
Also, 64 characters is a large percentage of a tweet or other constrained data input size, and definitely no fun to type in by hand either!
Get to da chopper!
What I am proposing here (and beginning to use for my own art), is both regular use of a hash algorithm like SHA 256 to take full “fingerprints” of your final art media, and then also truncating the long string down into a more usable version, something I’m choosing to call a “compact signature”.
This is your art media’s signature, not to be confused with your artist’s signature, which remains unaffected by this process.
You can use this shortened form of a SHA summary when the user interface (ui) or user experience (ux) of a website or dApp will not properly display the full summary, or when other character count constraints are in effect. So it can be included in the metadata for the NFT, thus adding richer informationn about the original media.
Demonstration with the Linux command line
“SHARPIE” 2020, (SuperRare)
Here is how one could use the Linux command line to obtain the SHA 256 summary of a PNG image.
In this case, the file is named
shasum -a 256 SHARPIE.png a4d6cf0f6970210a502c9b00d3e9e495a95bd1ddf289bb1dcb43a21069f04533 SHARPIE.png
Next, take the first 8 bytes of the summary value emitted from the command and concatenate it with the last 8 bytes, to form a 16-byte string.
a4d6cf0f | 6970210a502c9b00d3e9e495a95bd1ddf289bb1dcb43a210 | 69f04533 keep discard keep
After combining the strings, you have the compact signature value.
This method should also work as-is for the macOS Terminal, too.
Demonstration with Windows Powershell
PowerShell contains a built-in Get-FileHash utility. So the process is similar to that of the Linux command line. Here is an example with the same file.
Get-FileHash SHARPIE.PNG | Format-List Algorithm : SHA256 Hash : A4D6CF0F6970210A502C9B00D3E9E495A95BD1DDF289BB1DCB43A21069F04533 Path : SHARPIE.PNG
It’s the same hash/fingerprint/summary value as from the Linux example, just in all uppercase.
If you are not comfortable with command line interaction in terminal sessions, and prefer a GUI then there are some tools available. They accomplish the same task, but I have not personally tried any of these, so do your own research.
This more compact representation of significant bits to compare when user interfaces or other constraints make presentation of the full SHA256 summary string less attractive.
You should still store the full summary string as the source of truth, and to compare with the compact string since you cannot generate the full string with only access to the compact string.
You could of course, also still choose to publish full strings as part of a catalogue raisonné, for example.