This is an ongoing pain-point because it serves as an example of the very weird edges of the multicodec table. I'm not aware of any real use; or even how it could be practically used. It's not a "hash function", but describes a hash process that needs additional "function" information. I suspect it has its genesis in looking at Bitcoin et. al., but for those binary merkle trees we use bitcoin-tx coupled with dbl-sha2-256 which gives us all the information we need.
ssz-sha2-256-bmt is a newer example of an entry that's more descriptive, it stretches definitions a bit here but describes a hashing process within a format. It's probably not an awesome example either, but it's closer to a standard (current) understanding of multiformats than bmt is (not just because it can actually be implemented and used).
Can anyone think of a good reason to keep this entry, or can we remove it as cruft?
This is an ongoing pain-point because it serves as an example of the very weird edges of the multicodec table. I'm not aware of any real use; or even how it could be practically used. It's not a "hash function", but describes a hash process that needs additional "function" information. I suspect it has its genesis in looking at Bitcoin et. al., but for those binary merkle trees we use
bitcoin-txcoupled withdbl-sha2-256which gives us all the information we need.ssz-sha2-256-bmtis a newer example of an entry that's more descriptive, it stretches definitions a bit here but describes a hashing process within a format. It's probably not an awesome example either, but it's closer to a standard (current) understanding of multiformats thanbmtis (not just because it can actually be implemented and used).Can anyone think of a good reason to keep this entry, or can we remove it as cruft?