On 9/5/2013 6:55 AM, Richard Hipp wrote:
On Thu, Sep 5, 2013 at 6:27 AM, David Given <d...@cowlark.com <mailto:d...@cowlark.com>> wrote:playing with the encoder I see that: 12345678 = CRASH CHAPTER CASINO 123456 = ROVER TRIBAL EGO 1234 = JAMES ACTIVE 12 = ALCOHOL I think the above doesn't really work for an application like Fossil. I think that a prefix of the SHA1 hash should encode to a prefix of the mnemonic, and the other way around too - a prefix of the mnemonic should decode back to a prefix of the original hash....
I'm not convinced we ever need to generate the memorable name from any less information than the entire hash. We just need a prefix of the memorable name to match the entire name. I don't see a case for producing the name ad-hoc from a hash prefix like [12345] without the entire hash also being available. I think granting that relaxes the requirements enough that prefixes of memorable names can work just as well as the prefix of a hash does now.
One way to do that (again, blue sky, from someone not intimate with the insides of fossil) would be to cache the memorable names in a table where they can be located by SQL just as the prefix of a hash is now. In that case, you could easily match [CRASH-CHAP] too, even though CHAP isn't in the word list. (That might need to be a constraint on the word list: no word is a prefix of any other word.)
Another way to match a prefix from a (partial) memorable name is change the encoder to a big-endian process so that it is stable, then match can by decoding the words and trimming to just the number of bits represented, perhaps rounding down to entire hex digits, then proceed as usual for a hash prefix presented in hex.
-- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
