[JoshTriplett]

How would multihash handle parameterized algorithms like siphash, which take multiple arbitrary parameters? Adding every combination of "number of rounds" and "number of finalization rounds" as a separate table entry seems problematic.

[hobofan]

As long as the algorithm is sufficiently described, the parameters can be part of the body. So instead of `<hash-type><hash-result>` it would be `<hash-type><hash-rounds><hash-result>`.

[_prometheus]

@hobofan Yeah, exactly. We've explored this by making the value of such hashes (when generated and checked with multihash libs) literally be the `<hash-rounds><hash-result>` pair. This avoids complicating the table or multihash model/implementations. We can just redefine the hash function verify to use the first bits as the round, etc. We haven't done this yet, but we may.

[_prometheus]

See https://news.ycombinator.com/item?id=13740369 -- does that make sense? the idea is to treat those parameters as "part of the hash digest value", and write wrappers for siphash and functions like it, s.t.:

  mh_siphash_digest(input, length, rounds) {
    digest := siphash_digest(input, length, rounds)
    mhdigest := concat(rounds, digest)
    return mhdigest
  }

  mh_siphash_verify(input, mhdigest) {
    mh := multihash.parse(mhdigest)
    rounds := mh.digest[0]    # the rounds
    expected := mh.digest[1:] # rest
    actual := siphash_digest(input, mh.length, rounds)
    return expected == actual
  }

[JoshTriplett]

Makes perfect sense, thanks.